/home/user/public_html permissions

[barts]

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?

[nobaloney]

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

[barts]

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?

[smtalk]

Yes, it is. Why? Answer is here: http://directadmin.com/features.php?id=497

[barts]

Ok, but with chmod 755 to public_html security = 0 and with 750 apache doesn't have permissions to get scripts from public_html.

[nobaloney]

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

[barts]

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?

[Peter Laws]

and all scripts are secure.Apache execute scripts (php or cgi) as $USER (eg. usr1) so user nobody is used only by apache.
That sounds like cPanel is using PHP as CGI with suPHP.

[nobaloney]

And for maximum security with DirectAdmin, that's what you/we should be using with DirectAdmin as well.

Jeff

[barts]

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.

[nobaloney]

Please show us the results of these commands:

# ls -ald /home

# ls -ald /home/usr2

# ls -ald /home/usr2/public_html

# ls -ald /home/usr2/public_html/config.php
Jeff

[barts]

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.

[nobaloney]

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

[DirectAdmin Support]

This is the feature that addresses that:
http://www.directadmin.com/features.php?id=497

it sets the public_html folders to 750 and uses user:apache ownership.
Just set it to 1, restart DA.. and for any future new accounts, restores, new domains, etc.. it's set accordingly.

John

[nobaloney]

Thank, John.

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

Jeff

[DirectAdmin Support]

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

[DirectAdmin Support]

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.
usermod -G users usernamerepeat for all DA users. Then you can set the /home/username/domains folder to:
chown username:users domains
chmod 701 domainswhich 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:
cd /usr/local/directadmin/data/users
for i in `ls`; do { usermod -G users $i; }; done;
chgrp users /home/*/domains
chmod 701 /home/*/domainsUse 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

[nobaloney]

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

[DirectAdmin Support]

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.


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
#!/bin/sh
DIR=/home/$username/domains
chgrp access $DIR
chmod 710 $DIRand 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

[barts]

It should be:



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.

[DirectAdmin Support]

Hello,

Thanks, fixed.

Note, I've found that if you run backups, say under user "admin", /home/admin needs to be 711 becuase users need write access to the temp folder. So basically, you can have all users, except accounts that create Bacukps for their users. But you can still set /home/admin/domains to 710 admin:access to still hide his files.

I've created a guide here:
http://help.directadmin.com/item.php?id=254

John

[DirectAdmin Support]

I've changed it to set it on /home/username/domains instead of /home/username because of the backups issue. This is cleaner, but doesn't block viewing inside /home/user/* .. however, there really isn't much there (unless the user puts something there world readable)

John

[barts]

I use ftp backup and it works with chmod 710 /home/user

I see you change /home/user to /home/user/domains - but we can chmod 710 /home/user and 711 /home/resellers (and for resellers secure chmod 710 /home/reseller/domains).

Where is reseller list? It's still simple to do.


And why backup needs to have 711? It create backup of domains/mysql/mail and give error on some quota file.

[nobaloney]

We set /home/username/domains to 710,
chown username:access
John, I'm either missing something or confused.

Why does setting /home/username/domains to 710 do anything to mail at all, since mail uses /home/username/Maildir and /home/username/imap?

Thanks.

Jeff

[DirectAdmin Support]

It doesn't do anything for mail on domains, but leaves the opportunity to still throw in on /home/user if we change the script at all. The backup issue is in regards to other users, backing up on yourself doesn't have an effect. Also, it wouldn't be affected by ftp backups because they're assembled in /home/tmp/admin/user. Local backups are affected because they're assembled in /home/admin/admin_bacukps/user (for example) . We can still test more and change/improve as needed. And yes, I agree it's not difficult to change the script to check for Resellers/Admins. Probably a proof of concept test would be good for now, then we can get into more detail once potential issues are found/resolved.

Thanks!
John

[IMcomGuy]

Hi John,

Since implementing this on our servers, we've had issues with adding and deleting user accounts properly. It seems any loading of files placed within the public_html of new sites isn't loading properly. It continuously redirects everything back to the default login/control panel page for our main system account. I've verified DNS to be rolled over properly and everything is definitely resolving to our servers and IP's. I even manually forced /etc/hosts to point to the correct IP for the domains I added, as well as my local hosts file on my Windows machine to ensure there was definitely no remaining resolver issues.

Additionally, upon deleting an account, not everything is cleared out as it should be. The /home/user folder still exists with all the subfolders within (no files though), as well as the data folder of the user inside /usr/local/directadmin/data/users. Even after manually deleting these two locations, if you attempt to re-add the account to the server, it spits back:


Cannot Create Account



Details

That username already exists on the system

I would greatly appreciate any suggestions from anyone having the same issues as I am. I should also note, I implemented this upon your first post before the corrections were made and the knowledge base entry was created (which was causing forbidden errors, so I had to manually chmod everything back to how it was to get it working again). I since modified it to match everything in the kb entry and it seems it works great. Only minus the adding and removing of user accounts now.

Any ideas? Thank you. :)

[DirectAdmin Support]

Hello,

I'm not sure how it would be related to anything with DNS.. that may be a seperate issue. Also DA logins should't be affected by this either since the home directory isn't checked/required for DA logins really (unless I'm missing something). Double check the disk isn't full.

However the removal of User is most likely related to this change, so I'll be looking at it while I code this directly into the DA binaries as a new feature.

John

[IMcomGuy]

Thanks for looking into this.

It does not appear to be a disk space issue, "df" reports over 50 GB left on the primary drive. Not a quota issue either, so I'm stumped as to why it did this.

Good news though, I solved the user issue by "userdel -r user" eventually. This is the ugly way to do it, but it worked. There were also remnants in such places as /var/spool/mail/user, /etc/virtual, and a few other places, but I removed those prior to removing the user permanently from the system. After all this, I can re-add the domain and user just fine in DA now.

I am still struggling with why it will not load the public_html files when loading the domain in the browser (again, it goes to the CP login page, and the IP's are resolving correctly as expected). Yet somehow it DOES work when I use http://www.servername.com/~user. Now that's random.

It also looks like I can now add/remove users again just fine, although I didn't change anything to fix it. Maybe it was just a one time thing. I did notice the newly added /home/user is set 711, when all previous are 755. I thought the 710 (or 711) perms were only applied to /home/user/domains now? Maybe I am just nuts and did not understand this correctly or have something still set from the originally suggested shell command and custom modifications. Thanks again for your help.

[zEitEr]

I've set secure_access_group=access, as described on page http://directadmin.com/features.php?id=961

After that, I'm not able to get access to my emails via POP3/IMAP4.
I've got errors:


Apr 21 13:38:07 gw2 dovecot[3851]: Fatal: chdir(/home/userdomain/imap/userdomain/alexandr) failed with uid 1007: Permission denied

on our System user with uid 1007 is majordomo


# grep 1007 /etc/passwd
majordomo:*:1007:1:User &:/etc/virtual/majordomo/majordomo:/bin/sh

Adding majordomo to additional group access does not help.
chmod 711 /home/userdomain helps...

What is wrong?

[DirectAdmin Support]

Hello,

As I noticed when implementing the feature, for some reason the services need to get a full restart before new permissions are seen.. I'm not sure why this is, possibly something with a system cache.


Adding majordomo to additional group access does not help.it should.. just double check it's added:
grep access /etc/groupand restart exim.

John

[zEitEr]

Just the same. Restarting of exim and dovecot does not help, even with kill.


grep access /etc/group
access:*:1030:apache,nobody,mail,majordomo

But why Exim? Exim seems to me to work fine both with 711 and 710. No errors found.
The problem is to read the dilevered email via POP3/IMAP.

[DirectAdmin Support]

Try adding the daemon user as well.

Try restarting dovecot, or vm-pop3d and xinetd. (depending on which you have)
However, majordomo doesn't have anything to do with accessing pop/imap, hence I'd be confused as to why that user would be related to pop/imap.. hence I assumed it's exim.. as exim is what controls majordomo.

John

[zEitEr]

Thanks for your help, John.

My mistake. It's hard to remember why, but I had wrong uid (1007) for the user in /etc/virtual/userdomain/passwd. I've corrected uid, and now it works fine. Possibly the reason is in manual transfering the user from another server.

Regards,
Alex Gr.

[zEitEr]

Another problem has occured with spam delivering to system (default) e-mail for account. There're no problems with not-spam emails to such an e-mail.

Here, what we have in logs:


2009-04-22 14:50:30 /home/200172/Maildir/.INBOX.spam/new/ <analitika@userdomain.ru> R=domain_filter T=address_file defer (13): Permission denied: while creating file /home/200172/Maildir/.INBOX.spam/new//temp.49063.ns2.hostname
2009-04-22 14:51:46 /home/200172/Maildir/.INBOX.spam/new/ <analitika@userdomain.ru> R=domain_filter T=address_file defer (13): Permission denied: while creating file /home/200172/Maildir/.INBOX.spam/new//temp.74141.ns2.hostname
2009-04-22 14:54:52 /home/200172/Maildir/.INBOX.spam/new/ <analitika@userdomain.ru> R=domain_filter T=address_file defer (13): Permission denied: while creating file /home/200172/Maildir/.INBOX.spam/new//temp.36963.ns2.hostname


Already checked permissions on directory. Everything seems to be fine.

[zEitEr]

More information:

It does not matter to what e-mail address a message is sent.
If we set "Redirect spam to the catch-all ~/.spamassassin/spam folder.", we have the situation, described above on some accounts. No problems with others.

Double checked directory permissions manualy and with set_permissions.sh maildir <user> <path/Maildir>. Nothing helps.

[zEitEr]

Another problem has occured. Majordomo is not anymore able to read restrict_post file placed in user's home dir:


MAJORDOMO WARNING (mj_resend)!!

Can't read /home/userhome/allowsendaddress.txt: Permission denied

added majordomo to access group:


grep access /etc/group
access:*:1172:apache,nobody,mail,majordomo,daemon


permissions checked:


ls -l /home/userhome/allowsendaddress.txt
-rw-r--r-- 1 userhome mail 15 23 апр 13:25 /home/userhome/allowsendaddress.txt

[DirectAdmin Support]

Hello,

Thanks, I've added majordomo and daemon to the users in the access group.
Available for the next release of DA.

John

[zEitEr]

Hello, John.

Does that helped you? In my case adding majordomo and daemon to the users in the access group did not helped. I don't know why.

The problem is still not solved on my FreeBSD boxes.

[zEitEr]

Hello,

We still have got the issue with majordomo. So the question is:

Why majordomo is running processes with group daemon? Would it break anything, if we run it with group access?