Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15

[RFC] daemon whitelist handling (Re: git pull aborts in 50% of cases)

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:14

Having slept over the patch I am responding to, I tend to think
this is more trouble than its worth.  Validating the
directory enter_repo() chdir()'ed into and validated to be a
good git repository should be done on its canonical name as
getcwd() returns, not with a userland aliasing avoidance.

As an administrator, being able to say /pub/scm on the
whitelist, knowing /pub to be a symbolic link points at
somewhere today but maybe at different place tomorrow, and not
having to adjust the whitelist whenever that happens, is indeed
nice.  We do not allow the remote requestor to say /../ in the
path, so we trap him within the directories the whitelist
describes.

Not.

For example, I can by mistake create a symbolic link:

	ln -s /home /pub/scm/git/git.git/oops

now accesses /pub/scm/git/oops/hpa/secret.git/ is not
restricted.  We could hand-resolve the each level from the
request to see if no "funny" symbolic links are involved, but
what is the definition of "funny"?  When we see /pub pointing at
somewhere in /mnt/disk47/slice31, we should not complain.  When
we see "oops" under git in the above example, we would want to
complain.  These things are hard to get right.

I tend to say that the 0.99.9k (and the current master) rule to
make validation always work on what getcwd() gives back is
easier to understand (which generally means safer).  Can I talk
you into adjusting your whitelist on kernel.org machines?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help