On Tue, Jul 30, 2024 at 06:37:47AM -0500, W. Michael Petullo wrote: > 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. Makes sense, though I think it's somewhat specific to your setup / use case. If you had arbitrary clients connecting, telling them to use "-u" probably wouldn't scale. > 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. So there's an open question on the degree to which running upload-pack is actually dangerous. It's not _supposed_ to be, but the ownership check is a defense-in-depth approach to safety. > 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? It already is tied to the URL, in the sense that "clone" is not doing anything at all. It is entirely the server upload-pack that has started doing the ownership check (as of v2.45). For a local clone, the "server" is just another process owned by your user on the same machine, and that's where most people are running into it. But for all other remotes, the ownership issue is one for the server to deal with. So server operators serving over http or via git-daemon would need to make sure their daemon processes match the on-disk repository ownership (or use safe.directory to get around it). And there really is _potential_ danger there. The server-side daemon process is running upload-pack against a repository owned by some other user. If you're serving untrusted repositories that way (say, a system git-daemon with repositories owned by users), there could be a mismatch there (but again, this is defense-in-depth and upload-pack is supposed to be safe here). Cloning over ssh is sort of a middle ground. It still is the server's problem, and the "user" in this case is the user on the server side, not the user on the local machine running "git clone"). But often that user is conceptually the same entity (but doesn't have to be; as you can imagine, GitHub's ssh endpoint does not have one Unix user per conceptual user). > The current behavior seems to mean: > > (1) -c safe.directory works for some sub-commands, but not clone, Also fetch, push, ls-remote, etc. Anything dealing with a "remote" repository which spawn extra processes that clear the environment of "-c" config. > (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. Right. The workaround does work, though, if you're not using git-shell. > 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. Yes, I think that documentation is overly specific. The "-u" command is used whenever we can ask the other side to run an arbitrary command. So local clones, as well as ssh. Not git-daemon or http, where we just tell the other side the type of operation to perform. -Peff
