Thank you---from a somewhat sophisticated Git user, but not a Git developer---for all of the discussion that followed my initial inquiry. I thought I would follow up with some comments that follow from my reading of the responses and the SECURITY sections of various man pages. > [From Jeff:] 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. The discussion here is partially an attempt to better understand some of the internal workings and guarantees to determine whether or not the protections applied in some cases are spurious, right? > [From Brian:] Both of these commands should work correctly and do not, > and that's a bug (assuming tr1 is owned by a different user): > > git clone --no-local --no-hardlinks $PWD/tr1 tr2 > git clone --no-local --no-hardlinks ssh://localhost$PWD/tr1 tr2 The remarks above closely resemble the use cases that prompted my initial inquiry. It would help a great deal if these worked, and also if "--no-local --no-hardlinks" remains the default for the SSH variant. Is it fair to conclude that these not working represent a bug? > [From Brian:] The git(1) manual page also says this: > [...] but beware that the surface area for attack against > `upload-pack` is large Does the use of attack surface here mean the general idea of "the volume of lines of code in upload-pack is large and thus upload-pack likely contains bugs that might represent vulnerabilities", or is there something specific about upload-pack that should raise concern? I do have a related question on the SSH/push side. Let us imagine a host that has user accounts bearing git-shell as their shell. Thus these users can only interact with the host (and the repositories therein) using Git. Further imagine a trusted agent on the host creates these repositories and any hooks therein. Can a special account, with permission to access all of the repositories, safely clone and push other users' repositories? Or, could a user introduce a dangerous hook or configuration option to their remote repository using only Git by way of git-shell? Thank you again, especially Jeff, who provided me with some practical workarounds early in this thread. -- Mike :wq
