Quote:>It appears that if you turn off FollowSymLinks for your user directories,
>and if the path to your user's home directory contains symlinks, then
>NCSA httpd will fail when it hits the symlink. At the time that it tests
>the path for symlinks, in http_access.c:evaluate_access(), the users path
>has been resolved from /etc/passwd and the checker does not know that it
>is looking at a user's home directory.
This is a problem we've just noticed ourselves. Here's some further thoughts:
1. If the /home/<userid> symlink (or equivalent) were owned by <user>
the SymLinkIfOwnerMatch could be used instead. However, this presents
1. If the link is created by amd then it will be owned by root.
2. From a system security point of view, it should be owned by root anyway.
2. Given one, it occures to us that only root-owned symlinks prevent
serving user's home directories with Symlink restrictions.
3. Therefore, our proposed solution, and I patch I am working on for
bot httpd1.3R and for httpd1.4.1, is to 'bless' superuser-owned symlinks
and allow them to be followed despite access restrictions. There will
actually be two options in the patch, one that treats root-owned symlinks
as matching any owner, and one that always follows root-owned symlinks.
This seems like a rational solution. It allows home directories with
security restrictions, and only root can create security problems.
This seems acceptable, as if you can't trust root, you've got bigger
problems than web-served symlinks anyway.
I hope to have a patch tested and made available in a week or two,
and will announce to this group when done.
CRPC/CITI | tinker | it is funny that he should be killed for so
Rice Univ. | tailor | little, and the coin of his death should be
Houston TX | *naut | what we call civilization - R. Chandler