Re: [PATCH] setup: support GIT_IGNORE_INSECURE_OWNER environment variable

[Junio C Hamano <gitster@pobox.com>]

Phillip Wood <phillip.wood123@gmail.com> writes:

> On 26/06/2024 19:11, Junio C Hamano wrote:
>> Phillip Wood <phillip.wood123@gmail.com> writes:
>> 
>>> To expand an this a little - a couple of times I've wanted to checkout
>>> a bare repository that is owned by a different user. It is a pain to
>>> have to add a new config setting just for a one-off checkout. Being
>>> able to adjust the config on the command line would be very useful in
>>> that case.
>> True.  As long as it is deemed safe to honor the one-off "git -c
>> safe.directory=..." from the command line, for the purpose of this
>> "I who am running this 'git' process hereby declare that I trust
>> this and that repository", I think it would be the best solution
>> for the "git daemon" use case.
>
> This actually works already, the behavior was changed in 6061601d9f
> (safe.directory: use git_protected_config(), 2022-07-14). The reason I
> thought it didn't work was that I remember it failing on Debian
> bullseye a few months ago but that used an older version of git. There
> is some more rationale for the change in 779ea9303a7 (Documentation:
> define protected configuration, 2022-07-14)

Thanks.

So, does this more or less conclude the episode about how best to
deal with the 2.45.1 regression that Florian's patch in this thread
started?  It seems that we already have enough mechanisms to help
users tweak their existing set-up, so we may not need code changes,
but I am wondering if we want to add a bit of documentation around
safe.directory to tell them when it makes sense to set it, what
value(s) they would want to set it to, etc.

 * For "git daemon" invocations, because we know the command is run
   after chdir to a directory with '.' specified as the repository,
   we recommend to have safe.directory=., either on the command line
   with "-c var=val" or in daemon user's ~/.gitconfig, in the
   "git-daemon" help page?  We could recommend safe.directory=*, but
   they would mean the same thing in the context of running "git
   daemon".

   We may want to discuss who protects from whom with the
   safe.directory mechanism and git-daemon-export-ok mechanism.  The
   former is "the daemon trusts that repositories won't harm the
   daemon user", while the latter is "the repository owner is OK for
   it to be published".

   Also optionally, we may update the code to take the absolute path
   of the repository before passing it to the safe.directory check.

 * For "http-backend" invocations, we should think about potential
   additions that would help users, similar to what I listed above
   for "git daemon".

Having said all that, I do not think I mind GIT_SAFE_DIRECTORIES
that is a ":" separated list of paths that is honored just like the
multi-valued configuration variable safe.directory.  Once an
attacker can influence your environment variables, it already is
game over, so trusting it does not make the attack surface any
worse.  As Peff explained, we can trigger the more general "git -c
var=val" mechanism by exporting a set of environment variables, so
such a specialized environment variable is not strictly needed, but
it would make writing the "SetEnv" directive in apache configuration
(and similar ones for other HTTP server implementations) slighly
simpler and a lot more straight-forward.