Re: User-relative paths

Linus Torvalds [off-list ref] writes:

quoted

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