Re: Git clone reads safe.directory differently?
- From
- W. Michael Petullo <mike@flyn.org>
- Date
- Jul 30, 2024, 11:37 UTC
- Message-ID
- <ZqjQi6i2kiY4gcc1@imp.flyn.org>
- In-Reply-To
- <20240728224807.GA1299337@coredump.intra.peff.net>
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?
Show 5 quoted lines
> 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).
A little feedback to regarding why I chose to avoid .gitconfig along with some consequences:
I have a system built around Git in which I use the permissions approaches I have described in this email thread. The downside of .gitconfig is that its effect is global. I fear I might lose track of the fact that I have turned off a security protection in a global way, possibly years down the road as I maintain my system. Instead, I went about this by patching particular uses of Git to use "-c" and so on. I only needed to do this at two or three places my code executes Git out of dozens.
This makes my intention clear in the code (that executes Git) and lessens the likelihood of me (a year or so later?) forgetting I am responsible for ensuring the circumstances leave my use of safe.directory safe.
I suppose the inconsistency surrounding "-c" that we have discussed sort of works against my approach. Indeed, I wonder if in an ideal world we should remove the dangerous features that have good intentions (hardlinks and so on) and instead require users to opt in to them. I say ideal world because this ignores backward/forward compatibility issues.
Perhaps a compromise would be to tie safe.directory to the type of source directory given to clone. Would a remote URL be enough to turn off the safe.directory checks on a clone, similar to the effect of a remote URL on --local/--no-local?
The current behavior seems to mean:
(1) -c safe.directory works for some sub-commands, but not clone,
(2) clone requires your additional workaround, and
(3) your workaround does not work with SSH/git-shell for the obvious reason that git-shell needs to limit the "commands" it will run; this requires another level of intervention.
Another thing I came across was in the git-clone man page:
"When given, and the repository to clone from is accessed via ssh, this specifies a non-default path for the command run on the other end."
Your "-u 'git -c safe.directory=X upload-pack'" workaround uses upload-pack in the absence of SSH, so I wonder if "and the repository to clone from is accessed via ssh" is inaccurate.
-- Mike :wq