| 1 |
Hi Ognjen, |
| 2 |
on Monday, 2006-05-01 at 11:22:23, you wrote: |
| 3 |
> I have spent most of the day getting per user web serving to work |
| 4 |
> (/home/$user/public_html => http://server/~$user) but was constantly |
| 5 |
> getting "401 Forbidden" errors with apache2. |
| 6 |
> |
| 7 |
> After lots of hunting I found that you have to set the permissions for |
| 8 |
> the user directories to 755 (a+rx). So now it works, but all the users |
| 9 |
> can see each others home directories, which is unacceptable for this |
| 10 |
> server. |
| 11 |
> |
| 12 |
> So I am here to ask if anyone cen recommend a more secure way of doing |
| 13 |
> this. I |
| 14 |
|
| 15 |
My web server is still running an old SuSE system, but this should be |
| 16 |
basically the same. There are two ways to solve this. If you use the |
| 17 |
public_html subdirectory approach, $HOME only has to be o+x, so others |
| 18 |
can *enter* a user's directory but not *view* its contents. That should |
| 19 |
be acceptable if people use a safe umask. |
| 20 |
The reason we changed it a while ago was that we wanted to allow CGIs, |
| 21 |
at least for certain users some of which didn't know that much about |
| 22 |
input sanitizing 'n stuff, so a hacker could try to read other people's |
| 23 |
files by guessing their names---the web server would need access to the |
| 24 |
whole NFS-mounted parent of everybody's home. So now $HOME/public_html |
| 25 |
is just a link to /www/home/$USER which lives on the web server and is |
| 26 |
exported from there. That way a rogue CGI script could read other |
| 27 |
people's web pages which is far less critical. Of course you still have |
| 28 |
to check once in a while so you don't expose your passwd file or |
| 29 |
something. |
| 30 |
|
| 31 |
cheers! |
| 32 |
Matthias |
| 33 |
-- |
| 34 |
I prefer encrypted and signed messages. KeyID: FAC37665 |
| 35 |
Fingerprint: 8C16 3F0A A6FC DF0D 19B0 8DEF 48D9 1700 FAC3 7665 |
Archives