From: "René Scharfe" <l.s.r@web.de>
To: "Christian Göttsche" <cgzones@googlemail.com>, git@vger.kernel.org
Subject: Re: [PATCH] setup: avoid unconditional open with write flags
Date: Tue, 6 Dec 2022 20:47:09 +0100 [thread overview]
Message-ID: <f49b915e-46d1-7e53-ae4f-b01c2028b70d@web.de> (raw)
In-Reply-To: <20221205190019.52829-1-cgzones@googlemail.com>
Am 05.12.22 um 20:00 schrieb Christian Göttsche:
> Commit 57f5d52a942 ("common-main: call sanitize_stdfds()") added the
> sanitization for standard file descriptors (stdin, stdout, stderr) to
> all binaries. The lead to all binaries unconditionally opening
> /dev/null with the flag O_RDWR (read and write). Most of the time the
> standard file descriptors should be set up properly and the sanitization
> ends up doing nothing.
>
> There are many non modifying git operations, like `git status` or `git
> stash list`, which might be called by a parent to gather information
> about the repository. That parent might run under a seccomp filter to
> avoid accidental modification or unwanted command execution on memory
> corruptions. As part of that seccomp filter open(2) and openat(2) might
> be only allowed in read-only mode (O_RDONLY), thus preventing git's
> sanitation and stopping the application.
>
> Check before opening /dev/null to populate a possible non-present
> standard file descriptor if actually any is missing.
>
> Signed-off-by: Christian Göttsche <cgzones@googlemail.com>
> ---
> Alternatively one could add a command line argument
> (`--no-stdfd-sanitization`).
> ---
> setup.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/setup.c b/setup.c
> index cefd5f6..2af7170 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -1669,7 +1669,14 @@ const char *resolve_gitdir_gently(const char *suspect, int *return_error_code)
> /* if any standard file descriptor is missing open it to /dev/null */
> void sanitize_stdfds(void)
> {
> - int fd = xopen("/dev/null", O_RDWR);
> + int fd;
> +
> + if (fcntl(0, F_GETFD) != -1 &&
> + fcntl(1, F_GETFD) != -1 &&
> + fcntl(2, F_GETFD) != -1)
> + return;
> +
> + fd = xopen("/dev/null", O_RDWR);
> while (fd < 2)
> fd = xdup(fd);
> if (fd > 2)
If read-only access is allowed, how about this?
diff --git a/setup.c b/setup.c
index cefd5f63c4..0f52c51759 100644
--- a/setup.c
+++ b/setup.c
@@ -1669,7 +1669,12 @@ const char *resolve_gitdir_gently(const char *suspect, int *return_error_code)
/* if any standard file descriptor is missing open it to /dev/null */
void sanitize_stdfds(void)
{
- int fd = xopen("/dev/null", O_RDWR);
+ int 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)
Requires an extra open/close pair if fd 0 is already open, but no extra
syscalls if 0, 1 and 2 are all open.
Can opening /dev/null (or NUL on Windows) multiple times instead of dup'ing
cause issues? Can we e.g. lock ourselves out?
René
next prev parent reply other threads:[~2022-12-06 19:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-05 19:00 [PATCH] setup: avoid unconditional open with write flags Christian Göttsche
2022-12-05 22:13 ` brian m. carlson
2022-12-06 1:38 ` Jeff King
2022-12-06 16:15 ` Christian Göttsche
2022-12-05 22:59 ` Taylor Blau
2022-12-06 0:10 ` Junio C Hamano
2022-12-06 0:31 ` Taylor Blau
2022-12-06 0:40 ` Junio C Hamano
2022-12-06 19:47 ` René Scharfe [this message]
2022-12-06 23:39 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f49b915e-46d1-7e53-ae4f-b01c2028b70d@web.de \
--to=l.s.r@web.de \
--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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).