'safe.directory' setting ignored for some operations?

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

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

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

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.

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

On 2025-04-10 at 21:35:42, Jeff King wrote:

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.

On Thu, Apr 10, 2025 at 10:13:33PM +0000, brian m. carlson 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).

-Peff

On 2025-04-10 at 22:42:23, Jeff King wrote:

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.

On Thu, 10 Apr 2025 at 22:35, Jeff King <peff@peff.net> wrote:

Yes.

Exactly.

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

Best, -Nikolaus