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
