From: Junio C Hamano Date: Sun, 23 Oct 2005 22:57:34 GMT Subject: Re: User-relative paths Message-ID: <7vd5lvx2n5.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Linus Torvalds writes: >> But it is orthogonal to what you are doing in this patch. > > Well, not necessarily. > > It's quite arguable that sanity testing might be per-user and could be > done by the shell. I'm not at all sure that srvside_chdir() should do any > extra testing: if you have real ssh access, the user has the right to do > anything he damn well pleases. The point of the patch, unless I am mistaken, is to add ~user/ expansion to the pathname grokking, so that a remote user does not have to know exactly where on the server each user's home directory is. I agree 100% with you that srvside_chdir() is not the place to do policy checking. In order to avoid the aliasing problem (which motivated HPA to add --strict option), the receiving end, be it git-daemon driving upload-pack or git-shell driving receive-pack or upload-pack, can do ~user/ expansion first, then run their policy checking on the canonicalized path before spawning the lower level programs using the already canonicalized path. To also support the case where upload-pack and receive-pack are started directly from the ssh connection, these programs need to apply ~user/ expansion to the incoming path themselves by default. In order to avoid double expansion, git-daemon and git-shell should pass --no-user-expansion flag to the lower level programs when it starts them if we do this. A common library that takes the path supplied from the other end and does ~user/ expansion would be useful for the above; we can lift that logic from Andreas' srvside_chdir().