From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: "Christian Göttsche" <cgzones@googlemail.com>, git@vger.kernel.org
Subject: Re: [RFC PATCH v2] setup: avoid unconditional open syscall with write flags
Date: Wed, 28 Dec 2022 08:03:39 +0900 [thread overview]
Message-ID: <xmqqa638sb3o.fsf@gitster.g> (raw)
In-Reply-To: <221227.86lemsvqmb.gmgdl@evledraar.gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Tue, 27 Dec 2022 15:40:59 +0100")
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> + fd = xopen("/dev/null", O_RDONLY);
>> + if (fd > 0)
>> + close(fd);
>> + if (fd > 2)
>> + return;
>> +
>> + fd = xopen("/dev/null", O_WRONLY);
>> while (fd < 2)
>> fd = xdup(fd);
>> if (fd > 2)
>
> I don't really get this, if it's safe under seccomp to open this
> O_RDONLY wasn't it always redundant to use O_WRONLY, and this change
> should just be switching to O_RDONLY?
The first "if we successfully opened /dev/null and also found that
stdin is already connected to something above 0, then close the fd"
may be tricky to reason about. There are four cases.
(1) The first xopen(/dev/null, O_RDONLY) fails and returns -1.
In this case, we go down the original codepath.
(2) It returns 0 (upon startup, stdin was closed). We keep the fd
to use as the standard input, and go down the original
codepath, but now standard input is connected, the original
codepath needs to deal with only stdout and stderr, so we can
safely use O_WRONLY and dup it into stdout and stderr.
(3) It returns 1 or 2 (upon startup, stdin was open, stdin or
stderr was closed). The fd is closed, and we go to the
original codepath. Again, the original codepath does not have
to touch stdin, so we can afford to use O_WRONLY.
(4) It returns 3 or above, indicating that the three fd's we care
about was already open. We return without making further
damage after closing the fd.
The updated code does a single system call to probe for the lowest
unused file descriptor and returns in the common case. And that
single system call is an extra overhead for the "oops some of the
low FD were not open" case compared to the original code, but the
read-only FD may get reused when we need to.
So, I think the updated code does what it explains in its proposed
log message. I.e.
Check the need of sanitization with a file descriptor in read-only mode,
keep it as replacement for stdin and open replacement file descriptors
for stdout and stderr in write-only mode.
v2:
- switch to xopen("/dev/null", O_RDONLY) to stay at 2 syscalls in the
common case and use O_WRONLY for stdout and stderr, as suggested
by René Scharfe
prev parent reply other threads:[~2022-12-27 23:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 14:32 [RFC PATCH v2] setup: avoid unconditional open syscall with write flags Christian Göttsche
2022-12-27 14:40 ` Ævar Arnfjörð Bjarmason
2022-12-27 20:36 ` René Scharfe
2022-12-27 23:03 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqa638sb3o.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=cgzones@googlemail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).