From: Thomas Guyot <tguyot@gmail.com>
To: "J. Paul Reed" <preed@sigkill.com>, git@vger.kernel.org
Subject: Re: Odd git-config behavior
Date: Fri, 4 Nov 2022 07:47:46 -0400 [thread overview]
Message-ID: <bc3aa4b1-4716-cf9c-5dff-22b25793f66c@gmail.com> (raw)
In-Reply-To: <Y2A1bdiw6kGC65f/@sigkill.com>
Hi Paul,
On 2022-10-31 16:51, J. Paul Reed wrote:
> So... my maintenance automation runs as root, and the repo directories are
> uid/gid'd someone else (though, the config file inside the [bare] repo
> happens to be owned by root)... so I suppose what I'm observing is expected
> behavior?
You definitively shouldn't run these checks as root. Git is a highly
flexible/extensible product and god knows (and likely a few others in
this ML too) what could happen while you run git commands as root on an
"untrusted" user repository.
What prevents you from getting the owned uid or the repos and forking a
process as that user to run the check?
> I guess this leaves me with two questions:
>
> 1. Why does "git config" refuse to run due to this security check, but
> other git commands ("git fsck," at least) run?
Arguably a read-only config operation could likely be allowed, unless
there is a possibility for some untrusted commands to be executed as
part of this. I'm going to guess this was an easy entry point to cover
dangerous commands, but having a finer-grained check would require
making sure there's no dangerous code paths that could be exposed. The
change was to address CVE-2022-24765 - commit 8959555cee7 - so there was
likely time constraints to consider as well.
> 2. I think it might be useful to warn the user that the behavior they're
> expecting isn't happening due to this security check, instead of just
> outputting objectively wrong information (i.e. that no config options
> exist when they actually do exist); I'd be curious what others think.
What was the return code for the git config command? If it was zero when
it didn't parse/output the config option you asked for that is
definitively a bug. If you failed to check the return code of git-config
then you should fix your script/tool instead.
Regards,
--
Thomas
next prev parent reply other threads:[~2022-11-04 11:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-31 20:51 Odd git-config behavior J. Paul Reed
2022-11-04 11:47 ` Thomas Guyot [this message]
2022-11-08 23:08 ` J. Paul Reed
2022-11-09 7:02 ` Thomas Guyot
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=bc3aa4b1-4716-cf9c-5dff-22b25793f66c@gmail.com \
--to=tguyot@gmail.com \
--cc=git@vger.kernel.org \
--cc=preed@sigkill.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).