'safe.directory' setting ignored for some operations?

'safe.directory' setting ignored for some operations?

[Nikolaus Rath]

Hello,

It seems to me that the 'safe.directory = *' option is ignored for
some operations:

---snip--
$ git --version
git version 2.43.0

$ git config --get-all --show-scope safe.directory
command *

$ git status -v --untracked=all --ignored
HEAD detached at e116555
[...]
nothing to commit, working tree clean

$ git clone -v --no-checkout --
/builds/coreinfra/grafana_terraform/.git
/builds/coreinfra/grafana_terraform/tmpus18hzbs
Cloning into '/builds/coreinfra/grafana_terraform/tmpus18hzbs'...
fatal: detected dubious ownership in repository at
'/builds/coreinfra/grafana_terraform/.git'
To add an exception for this directory, call:

git config --global --add safe.directory
/builds/coreinfra/grafana_terraform/.git
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
---snip--


Is this a known issue, or working as intended?

(Without setting safe.directory, both `git status` and `git clone`
fail as expected).

Best,
-Nikolaus

-- 
nikolaus@quadrature.ai
https://quadrature.ai
Dir: +44-20-8145-4726 Main: +44-20-3743-0400
The Leadenhall Building, 122 Leadenhall Street, London, EC3V 4AB

Re: 'safe.directory' setting ignored for some operations?

[Jeff King]

On Thu, Apr 10, 2025 at 02:21:01PM +0100, Nikolaus Rath wrote:

> It seems to me that the 'safe.directory = *' option is ignored for
> some operations:
> 
> ---snip--
> $ git --version
> git version 2.43.0
> 
> $ git config --get-all --show-scope safe.directory
> command *

You're getting "command" here, but I don't see any "-c". Presumably
you're setting GIT_CONFIG_* in the environment yourself?

> $ git status -v --untracked=all --ignored
> HEAD detached at e116555
> [...]
> nothing to commit, working tree clean

You don't show us the repo here, but presumably this is one you don't
own, and the config is working as expected to allow the operation to
proceed.

> $ git clone -v --no-checkout --
> /builds/coreinfra/grafana_terraform/.git
> /builds/coreinfra/grafana_terraform/tmpus18hzbs
> Cloning into '/builds/coreinfra/grafana_terraform/tmpus18hzbs'...
> fatal: detected dubious ownership in repository at
> '/builds/coreinfra/grafana_terraform/.git'
> To add an exception for this directory, call:
> 
> git config --global --add safe.directory
> /builds/coreinfra/grafana_terraform/.git
> fatal: Could not read from remote repository.
> 
> Please make sure you have the correct access rights
> and the repository exists.

Here you are running afoul of the environment-clearing that happens when
Git internally "switches" to another repo. The "clone" command is run in
your newly-made repo (which is "safe"), but it would then run
"git-upload-pack" in the remote repo to act as the server side. We clear
out many Git-related environment variables when switching between
variables, including GIT_CONFIG_*.

  Side note: clearing out the config has been a subject of debate over
  the years, but one of the main reasons we do it is to be consistent
  with non-local transports, which do not pass environment variables at
  all. Which is good for some config, but can be annoying for others, as
  seen here.

So I think things are working as intended. You can get around it with
either of these:

  - set the config in your user ~/.gitconfig, which will be read by the
    child upload-pack command

  - tell clone to pass the config to upload-pack, like:

     git clone -u 'git -c safe.directory="*" upload-pack' ...

-Peff

Re: 'safe.directory' setting ignored for some operations?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On 2025-04-10 at 21:35:42, Jeff King wrote:
> So I think things are working as intended. You can get around it with
> either of these:
> 
>   - set the config in your user ~/.gitconfig, which will be read by the
>     child upload-pack command
> 
>   - tell clone to pass the config to upload-pack, like:
> 
>      git clone -u 'git -c safe.directory="*" upload-pack' ...

I think you can also use `git clone --no-local` in a more recent version
and the normal clone-from-untrusted-repository semantics will kick in
and things will work.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: 'safe.directory' setting ignored for some operations?

[Jeff King]

On Thu, Apr 10, 2025 at 10:13:33PM +0000, brian m. carlson wrote:

> On 2025-04-10 at 21:35:42, Jeff King wrote:
> > So I think things are working as intended. You can get around it with
> > either of these:
> > 
> >   - set the config in your user ~/.gitconfig, which will be read by the
> >     child upload-pack command
> > 
> >   - tell clone to pass the config to upload-pack, like:
> > 
> >      git clone -u 'git -c safe.directory="*" upload-pack' ...
> 
> I think you can also use `git clone --no-local` in a more recent version
> and the normal clone-from-untrusted-repository semantics will kick in
> and things will work.

Yeah, that's true in v2.48.0 and later. (I tried it after writing the
earlier email and was a little puzzled that it works with --no-local but
not otherwise, but it sounds like that's known).

-Peff

Re: 'safe.directory' setting ignored for some operations?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On 2025-04-10 at 22:42:23, Jeff King wrote:
> Yeah, that's true in v2.48.0 and later. (I tried it after writing the
> earlier email and was a little puzzled that it works with --no-local but
> not otherwise, but it sounds like that's known).

It is.  The reason for that is that we try to hardlink if `--no-local`
is not provided, which has all the normal security concerns across
ownership boundaries.  However, `--no-local` uses the normal
`git-upload-pack` mechanism, which we know is secure on untrusted
repositories.

One thing we could do to improve things is detect if the repository is
owned by another user and just set `--no-local` automatically, but
that's a #leftoverbits for someone.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: 'safe.directory' setting ignored for some operations?

[Nikolaus Rath]

On Thu, 10 Apr 2025 at 22:35, Jeff King <peff@peff.net> wrote:
>
> On Thu, Apr 10, 2025 at 02:21:01PM +0100, Nikolaus Rath wrote:
>
> > It seems to me that the 'safe.directory = *' option is ignored for
> > some operations:
> >
> > ---snip--
> > $ git --version
> > git version 2.43.0
> >
> > $ git config --get-all --show-scope safe.directory
> > command *
>
> You're getting "command" here, but I don't see any "-c". Presumably
> you're setting GIT_CONFIG_* in the environment yourself?


Yes.

>
> > $ git status -v --untracked=all --ignored
> > HEAD detached at e116555
> > [...]
> > nothing to commit, working tree clean
>
> You don't show us the repo here, but presumably this is one you don't
> own, and the config is working as expected to allow the operation to
> proceed.


Exactly.

>
> > $ git clone -v --no-checkout --
> > /builds/coreinfra/grafana_terraform/.git
> > /builds/coreinfra/grafana_terraform/tmpus18hzbs
> > Cloning into '/builds/coreinfra/grafana_terraform/tmpus18hzbs'...
> > fatal: detected dubious ownership in repository at
> > '/builds/coreinfra/grafana_terraform/.git'
> > To add an exception for this directory, call:
> >
> > git config --global --add safe.directory
> > /builds/coreinfra/grafana_terraform/.git
> > fatal: Could not read from remote repository.
> >
> > Please make sure you have the correct access rights
> > and the repository exists.
>
> Here you are running afoul of the environment-clearing that happens when
> Git internally "switches" to another repo. The "clone" command is run in
> your newly-made repo (which is "safe"), but it would then run
> "git-upload-pack" in the remote repo to act as the server side. We clear
> out many Git-related environment variables when switching between
> variables, including GIT_CONFIG_*.


Ah, that explains it indeed. Thank you very much! And apologies for
not being fully clear about the context.

Best,
-Nikolaus

-- 
nikolaus@quadrature.ai

https://quadrature.ai
Dir: +44-20-8145-4726 Main: +44-20-3743-0400
The Leadenhall Building, 122 Leadenhall Street, London, EC3V 4AB