On Thu, May 5, 2022 at 7:01 AM Johannes Schindelin
<Johannes.Schindelin@xxxxxx> wrote:
> On Mon, 2 May 2022, Carlo Marcelo Arenas Belón wrote:
> > bdc77d1d685 (Add a function to determine whether a path is owned by the
> > current user, 2022-03-02) checks for the effective uid of the running
> > process using geteuid() but didn't account for cases where that user was
> > root (because git was invoked through sudo or a compatible tool) and the
> > original uid that repository trusted for its config was no longer known,
> > therefore failing the following otherwise safe call:
> >
> > guy@renard ~/Software/uncrustify $ sudo git describe --always --dirty
> > [sudo] password for guy:
> > fatal: unsafe repository ('/home/guy/Software/uncrustify' is owned by someone else)
> >
> > Attempt to detect those cases by using the environment variables that
> > those tools create to keep track of the original user id, and do the
> > ownership check using that instead.
> >
> > This assumes the environment the user is running on after going
> > privileged can't be tampered with, and also adds code to restrict that
> > the new behavior only applies if running as root, therefore keeping the
> > most common case, which runs unprivileged, from changing, but because of
> > that, it will miss cases where sudo (or an equivalent) was used to change
> > to another unprivileged user or where the equivalent tool used to raise
> > privileges didn't track the original id in a sudo compatible way.
>
> Hmm. I do realize that this is a quite common scenario, and I wish we
> would not need to rush for a fix here:
not sure what are you referring by "this", and I read the whole snip
just in case, but assuming is about the last paragraph
* sudo between unprivileged users is still safe because we only look
if we are running as root, my comment doesn't imply a regression
there, but just that the "feature" wouldn't work for them.
* doas is a common tool that is used sometimes as a sudo alternative
and I can see there might be even a version of it that would probably
provide a SUDO_UID for compatibility, once word goes out of how useful
that is for working with git, but until then only sudo is supported.
> Otherwise we could carefully design
> an "untrusted" mode in which Git errors out on spawning user-specified
> commands and on writing files (and avoids refreshing the index to avoid
> having to write a file), but runs normally if none of that is needed.
This seems like a useful feature to have, and would definitely make
this solution irrelevant, but this one is already implemented and I
don't see yet why there is concern, probably until "this" could be
clarified.
> > diff --git a/Documentation/config/safe.txt b/Documentation/config/safe.txt
> > index 6d764fe0ccf..ee558ced8c7 100644
> > --- a/Documentation/config/safe.txt
> > +++ b/Documentation/config/safe.txt
> > @@ -26,3 +26,12 @@ directory was listed in the `safe.directory` list. If `safe.directory=*`
> > is set in system config and you want to re-enable this protection, then
> > initialize your list with an empty value before listing the repositories
> > that you deem safe.
> > ++
> > +When git tries to check for ownership of git repositories, it will
> > +obviously do so with the uid of the user that is running git itself,
> > +but if git is running as root, it will check first if it might have
> > +been started through `sudo`, and if that is the case, will instead
> > +use the uid of the user that did so.
> > +If that is not what you would prefer and want git to only trust
> > +repositories that are owned by root instead, then you should remove
> > +the `SUDO_UID` variable from root's environment.
> > diff --git a/git-compat-util.h b/git-compat-util.h
> > index 63ba89dd31d..dfdd3e4f81a 100644
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -393,12 +393,50 @@ static inline int git_offset_1st_component(const char *path)
> > #endif
> >
> > #ifndef is_path_owned_by_current_user
> > +
> > +#ifdef __TANDEM
> > +#define ROOT_UID 65535
> > +#else
> > +#define ROOT_UID 0
> > +#endif
>
> I do wonder whether we have to play this kind of fragile game. Why not
> simply respect `SUDO_UID` if it is set? It's not like we expect attackers
> to have control over the environment and could set this maliciously.
The problem is that it indeed would lower the bar on how this feature
might weaken the current protections.
Getting an environment variable set "maliciously" is not that hard
with some social engineering, so making sure only root would have that
escape hatch, and knowing that there is a way to infer from the
environment what the relevant user is, is a powerful way to solve this
regression without making the protections weaker.
My original implementation did not use SUDO_UID but the owner of the
pty as that is harder to fake, and therefore safer even for non root
users, but it makes it much more intrusive for the same reason.
If your concern is the introduced regression where `sudo git` will no
longer work without adding a safe.directory exception or removing
SUDO_UID from the environment (or another of the workaround documented
in the test case), I would actually argue that it instead increases
the security of the original solution by implementing a mechanism that
user can use to communicate their intention and that would prefer the
lower privilege by default.
Still I am considering it as a "known bug" which will hopefully be
fixed soon, since Junio already provided the code to improve this one
so that a root user can access both repositories owned by them and by
their SUDO_UID.
Carlo
