Re: User-relative paths

From: Junio C Hamano <junkio@cox.net>
Date: Oct 23, 2005, 22:57 UTC
Message-ID: <7vd5lvx2n5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0510231427230.10477@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 8 quoted lines

>> 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().