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

From: H. Peter Anvin <hpa@zytor.com>
Date: Dec 3, 2005, 19:41 UTC
Message-ID: <4391F4DD.2060002@zytor.com>
In-Reply-To: <7vzmnivuz8.fsf_-_@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 13 quoted lines

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

Actually, it's a policy decision whether or not symlinks should be allowed to exit space like that; in Apache, for example, it's a configurable.

> 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?

I'm not happy about it, but it's not a huge deal on kernel.org. However, I think it's the wrong thing, especially in the light of allowing user-relative paths.

At the very least, if you insist on using getcwd() names, you should pre-canonicalize the whitelist, too.

	-hpa