Thread (7 messages) 7 messages, 3 authors, 2024-07-31

Re: Git clone reads safe.directory differently?

From: Jeff King <hidden>
Date: 2024-07-28 22:48:15

On Sun, Jul 28, 2024 at 10:27:00AM -0500, W. Michael Petullo wrote:
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!).
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help