/home/user/public_html permissions

B

barts

Verified User
Joined
Nov 22, 2005
Messages
29
[security] /home/user/public_html permissions

Hi,

after install DA and add some users and domains I saw bug in folders permissions.
From user user1 I can read files from /home/user2/public_html/ from shell and from php. I know that I can disable functions in php.ini but I have still access by shell to other users. How can I change permissions to new added folders /home/user/domains/* to 750 and chgrp this files/folders to user apache?
Maybe is another way to fix it?
 
Last edited:
Why don't you show us the permissions and ownership you've got now?

Changing ownership to apache is the least secure; anyone on the 'net has access to all the files.

Jeff
 
Permissions for public_html:

drwxr-xr-x 28 usr1 usr1 8192 mar 6 14:56 public_html

r-x for all users - is it default?
 
Ok, but with chmod 755 to public_html security = 0 and with 750 apache doesn't have permissions to get scripts from public_html.
 
For directories you need to have both read and execute access for other, in order for apache to read files in public_html. That's the 5 in 755.

Jeff
 
Ok i understand, but it isn't secure. Everyone can read files eg. config.php with database passwords.

I have server with cPanel:

drwxr-x--- 17 usr1 nobody 4096 sty 28 22:30 public_html/

and all scripts are secure.
Apache execute scripts (php or cgi) as $USER (eg. usr1) so user nobody is used only by apache.

You know DA better so can you tell me how can I secure public_html?
 
And for maximum security with DirectAdmin, that's what you/we should be using with DirectAdmin as well.

Jeff
 
Sorry but I don't understand that. I use DA with php-cgi with suPHP and I can read /home/usr2/public_html/config.php as usr1 (from php).
It's not secure.
 
Please show us the results of these commands:
Code: 
# ls -ald /home
Code: 
# ls -ald /home/usr2
Code: 
# ls -ald /home/usr2/public_html
Code: 
# ls -ald /home/usr2/public_html/config.php
Jeff
 
CentOS 5.2 and fresh DA - linux and DA installed few days ago.

# ls -ald /home
drwx--x--x 10 root root 4096 mar 10 18:36 /home

# ls -ald /home/usr2
drwx--x--x 5 usr2 usr2 4096 mar 10 11:14 /home/usr2

# ls -ald /home/usr2/public_html
lrwxrwxrwx 1 usr2 usr2 33 mar 10 11:12 /home/usr2/public_html -> ./domains/usr2domain.com/public_html

# ls -ald /home/usr2/public_html/index.html
-rw-r--r-- 1 usr2 usr2 610 mar 10 11:12 /home/usr2/public_html/index.html

index.html is default DA file after useradd. I can read it from usr1.
 
Okay, I see what you mean ...

Because apache has to traverse the directory path from /home, the path has to have --x rights for each domain for "others", to be able to traverse into the directory. So if us2 is logged in through the shell he's counted as an "other". And while he can't read the directory, he can traverse it through to a file he can read. He can't read the directory so he has to know the file name, but knowing it he can still read it.

How to get around it? I'm thinking perhaps ownership of usr2:apache for the directory structure through public_html, with 710 (drwx--x---) instead of 711 (drwx--x--x).

If this doesn't work then the only real option is to offer either no shell access or only chrooted shell access.

Anyone else care to discuss this?

John?

Jeff
 
Thank, John.

Is there a good reason why all servers shouldn't have this enabled by default?

Jeff
 
Hello,

Yes, a lot of boxes end up creating all files in that folder with group apache, when uploading through ftp. This breaks cgi-bin files, as well as frontpage files (less important). It would be easier to simply do a 1 time chgrp/chown to the /home/user/domains folder in that fashion, but then that breaks the anonymous ftp access, which connects as "nobody".

John
 
I've been playing around a bit with more advanced linux group options. I found that you can add all users to a group, lets call it "users" for simplicity.
Code: 
usermod -G users [B]username[/B]
repeat for all DA users. Then you can set the /home/username/domains folder to:
Code: 
chown [B]username[/B]:users domains
chmod 701 domains
which is sort of the negation of the previous method. The way this works is it says to deny anyone who is in the users group from accessing the domains folder. As long as the uid "nobody" is not in the users group, then anonymous ftp access would still work. As long as all DA users are in the "users" group, none of them would be able to see below the domains folder. The apache user would not be in the users group, so it could see in.. and you'd use open_basedir to prevent other php scripts from peering in (or just use suPhp). The webapps user (in theory) should be in the users group, since he shouldn't see in.

This method has not been extensively tested by me, but I thought it should be mentioned as another option that is avaiable for "creative" permissions.

Note that a user who is in the users group can still see his own domains folder, since the user chmod has priority over the denied group chmod.. key in making this work.

If anyone wants to try this (again, I've not tested it, so not sure if there are any issues), you can type:
Code: 
cd /usr/local/directadmin/data/users
for i in `ls`; do { usermod -G users $i; }; done;
chgrp users /home/*/domains
chmod 701 /home/*/domains
Use this at your own risk... only do it if you understand these concepts and have the knowhow to undo it should there be any issues with it ;)

The user_create_post.sh custom script should be used as well to auto-add the user to the users group.

John
 
I have a testbed server available; will someone be willing to test? If so let me know, and I'll give you a CentOS5 install and a DirectAdmin LID/UID, and you can install however you want and do some testing.

Just write me at the email address below in my siglines.

Note this offer could expire by next month; we're changing how we do testbeds, and I'm giving up static IP where the current testbeds sit.

So let me know soon ;).

Jeff
 
Hello,

Idea! ;)

Clean, simple, effective.
Initial tests show it works, nothing messy, and without the ugly group negation.

We set /home/username/domains to 710,
chown username:access

where group "access" is a group allowing apache (httpd), nobody (anon ftp) and mail (exim, dovecot) to see in.

Code: 
groupadd access
usermod -G access apache
usermod -G access nobody
usermod -G access mail
for i in `/bin/ls /usr/local/directadmin/data/users`; do { chgrp access /home/$i/domains; chmod 710 /home/$i/domains; }; done;
I can see no reason why this wouldn't solve everything.

It doesn't break suPhp or cgi-bin because public_html is still user:user 755.
Anon ftp works still because it lets the "nobody" user in.

For now, we can use /usr/local/directadmin/scripts/custom/user_create_post.sh
Code: 
#!/bin/sh
DIR=/home/$username/domains
chgrp access $DIR
chmod 710 $DIR
and chmod user_create_post.sh to 755.

This may be what we're all looking for if it pans out.

EDIT: you must restart exim. It seems to cache things and cant see /home/user/.shadow, but can see .shadow after you restart exim.

John
 
It should be:

Code: 
for i in `/bin/ls /usr/local/directadmin/data/users`; do { chgrp access /home/$i; chmod 710 /home/$i; }; done;

I restarted apache and exim. I use suphp and chmod 750 in public_html.
All works fine.
 
You must log in or register to reply here.
Back
Top