Re: Git clone reads safe.directory differently?

From: Jeff King <peff@peff.net>
Date: Jul 28, 2024, 22:48 UTC
Message-ID: <20240728224807.GA1299337@coredump.intra.peff.net>
In-Reply-To: <ZqZjRMqpEV_3WIkD@imp.flyn.org>

On Sun, Jul 28, 2024 at 10:27:00AM -0500, W. Michael Petullo wrote:

Show 12 quoted lines

> For completeness, I investigated how to do the same over SSH. Imagine a
> repository user-owned by Bob, but group-owned with r/w/x permissions by
> a group containing Alice. It seems the same trick fails because git-shell
> rejects the custom upload-pack command:
> 
> 	git -c safe.directory="*" clone -u 'git -c safe.directory="*" upload-pack' alice@git.example.com:/shared/repository
> 	Cloning into 'git'...
> 	fatal: unrecognized command 'git -c safe.directory="*" upload-pack '/shared/repository''
> 	fatal: Could not read from remote repository.
> 
> 	Please make sure you have the correct access rights
> 	and the repository exists.

It should work over ssh in the general case, but yes, if you're using git-shell, the whole idea there is to restrict what the client can specify. And so there won't be any workaround from the client side (if there were, it would be a bug!).

Show 13 quoted lines

> I was able to overcome this by creating /home/alice/git-shell-commands/upload-pack-safe,
> placing the following there
> 
> 	#!/bin/sh
> 
> 	git -c safe.directory="$1" upload-pack $1
> 
> and running:
> 
> 	git -c safe.directory="*" clone -u upload-pack-safe alice@git.example.com:/shared/repository
> 
> This seems to be another interface edge case. Is my solution reasonable,
> or is there something else that would be more consistent?

So yeah, that would work. But it might be simpler still to just put "[safe]directory = *" into /home/alice/.gitconfig. Then the client side does not have to do anything differently (or you could even put in a more limited relaxation of the rules, like "/shared/repository/*" or whatever).

-Peff