Knowledgebase
How to prevent Users from seeing in each other's public_html folders
new way
Note, as of DirectAdmin 1.33.3, this has been integrated into the DirectAdmin binaries, so no need to do it manually below.
See this guide
old way
Apache requires that the "apache" user be able to read all files belonging to a User, so that it can send them to a client during that client's request. There are two ways to go about that.
1)The first is to make these files world readable on the system. This allows the folders to remain chowned to the user:user, thus not causing any ownership issues for suPhp, cgi-bin files, and Frontpage. The downside is that anyone on the system can read these files, including their potentially sensitive information.
2)The 2nd is to setup a group on the public_html folder so that the folder can be chmod 750 (user+group access only, not world readable). This satisfies things from the permissions perspective, but fails to function for suPhp, cgi-bin files, and frontpage.
The possible solution was to move the apache group higher up in the directory tree, but this caused other problems because anonymous ftp requires access by the "nobody" user, and higher up still the "mail" user needs access for mail related activity.
A solution was found where we create another group called access such that it contains all 3 of these users (apache, nobody, mail). Implementation is shown below.
How to secure your User's /home/username/domains directories.
1) Create the new access group and add all required system accounts.
2) To set the correct ownership/permissions for existing DirectAdmin accounts, run the following:
3) You will need to restart all of your services. This is because (for a reason which I cannot explain) the system does not always re-check new chown/chmod permissions, and for some reason they don't have correct access until you restart them (no config changes). Restart the services via the appropriate commands for your OS. Debian/Linux:
4) Create the script:
NOTE: The above script sets the permissions/ownership onto /home/username/domains. This could be done on /home/username instead, which would be better, but for Admins and Resellers, they require their /home/user/user_backups and /home/user/admin_backups to be world +x, hence we moved it to "domains" instead. You can set /home/username this way for everyone except accounts that need to create backups for their users.
Note, as of DirectAdmin 1.33.3, this has been integrated into the DirectAdmin binaries, so no need to do it manually below.
See this guide
old way
Apache requires that the "apache" user be able to read all files belonging to a User, so that it can send them to a client during that client's request. There are two ways to go about that.
1)The first is to make these files world readable on the system. This allows the folders to remain chowned to the user:user, thus not causing any ownership issues for suPhp, cgi-bin files, and Frontpage. The downside is that anyone on the system can read these files, including their potentially sensitive information.
2)The 2nd is to setup a group on the public_html folder so that the folder can be chmod 750 (user+group access only, not world readable). This satisfies things from the permissions perspective, but fails to function for suPhp, cgi-bin files, and frontpage.
The possible solution was to move the apache group higher up in the directory tree, but this caused other problems because anonymous ftp requires access by the "nobody" user, and higher up still the "mail" user needs access for mail related activity.
A solution was found where we create another group called access such that it contains all 3 of these users (apache, nobody, mail). Implementation is shown below.
How to secure your User's /home/username/domains directories.
1) Create the new access group and add all required system accounts.
groupadd access
usermod -a -G access apache
usermod -a -G access nobody
usermod -a -G access mail
usermod -a -G access nginx
2) To set the correct ownership/permissions for existing DirectAdmin accounts, run the following:
for i in `/bin/ls /usr/local/directadmin/data/users`; do { chgrp access /home/$i/domains; chmod 710 /home/$i/domains; }; done;
3) You will need to restart all of your services. This is because (for a reason which I cannot explain) the system does not always re-check new chown/chmod permissions, and for some reason they don't have correct access until you restart them (no config changes). Restart the services via the appropriate commands for your OS. Debian/Linux:
/etc/init.d/exim restart
/etc/init.d/dovecot restart
/etc/init.d/directadmin restart
/etc/init.d/httpd restart
/etc/init.d/proftpd restart
4) Create the script:
/usr/local/directadmin/scripts/custom/user_create_post.sh
and in it place the following code, then chmod the script to 755:#!/bin/sh
DIR=/home/$username/domains
chgrp access $DIR
chmod 710 $DIR
exit 0;
NOTE: The above script sets the permissions/ownership onto /home/username/domains. This could be done on /home/username instead, which would be better, but for Admins and Resellers, they require their /home/user/user_backups and /home/user/admin_backups to be world +x, hence we moved it to "domains" instead. You can set /home/username this way for everyone except accounts that need to create backups for their users.