Some web hosts allows you to create multiple users per account. Each user can have domain assigned to its home home directory accessible via FTP or SSH/SCP. The problem with multiple users on the same account is that they share the same default unix group, and default permissions allow their files to be easily modified by the members of this group. Usually this doesn’t pose a problem as each user is probably trusted by account owner to not to mess with others files, but if one of the users have their web application hacked then all other users on the same account will be in danger.
By default (on DreamHost) all files in your account are created with 644 privileges and directories are with 775. That means any user can read your files and any user from the same account can move and add files in your freshly made directories. Your home directory is different, though. By default it carries 751 attribute meaning that only members of your group can see your files, but can’t add any new. These group access schemes are possible, because every user in your account has its primary/default group set to “pgxxxxxx”, which is assigned to every new file you create by default. The normal way to secure users from web-intrusion is to assign a separate group to the web-server user, removing it from default group. This way, exploited scripts will not be able to traverse into home directories of other users on your account. To allow account users to update centralized web-site they could be added to web-site group explicitly. But this “normal way” doesn’t work with DreamHost, because you can’t delete web-user from the default group and unless you set access for every new file explicitly, it will be possible for an intruder to read it.
To make managing privileges easier in interactive sessions “umask 007″ command can be specified in your .bash_profile – this makes all new files carry xx0 mask. You also need to control your scripts (web based or cron/shell) so that they set mask for critical files explicitly. To secure account users from access by means of hacked user script you would also like to define another group for every user in your account and change group ownership of the user’s home directory to that group with “set gid” bit set (and optional umask 007 in .bash_profile).
- Add a separate user and group for every domain where apache will be running
- Add a separate group for other user accounts
- Change the default group for new files created by your users by changing the group of their home directory and setting set gid bit for it (it is impossible to do this with FTP accounts, therefore you will need to login in each account via SSH)
- Add users who need access to web-site into the web-user group
- Optionally set umask 007 in .bash_profile for every user to tweak default DreamHost 775/664 permissions to something like 770/660 for directories and files that are not meant to be read by Apache (660 could also be used for all web scripts including .php as they are not read by dhapache CGI, but merely executed)
Apache Security
All your web files that need to be read by Apache should be readable by everyone as Apache itself is run under dhapache user. However, executable scripts like .php are executed under your own user and do not have to be world readable as they are not actually read by Apache, but executed via suEXEC. Quite the opposite – to prevent your code or database settings from being messed by any third-parties you SHOULD set permissions to these files explicitly to something like 640 or even 600 depending on who do you trust.
Multiuser security setup example
For our example, we will create a example_www user and a new_webroot group for serving web files with apache and setup a example user with a ‘rfrc group to manage mail and keep other files on DH privately. Since these records already exist, you will need to subsitute your own names.
- Login to DreamHost panel and create the users example_www and example with shell access.
- From groups tab create two groups – new_webroot and rfrc. Note that users created in previous step are still members of the same default pgxxxxxx group.
- Add example_www to ‘the ‘new_webroot group and example to both the new_webroot and rfrc groups
- Move your domain to example_www account (mine is example.org)
- Now login to SSH with your example_www user and change the default group for your home directory with “sgid” bit set to make all current and new files/directories created in this directory have the same new_webroot group.
$ chgrp -R new_webroot . $ chmod 2751 . $ chmod 2771 example.org
By setting 2771 the directory will be writable by the owner, the group and will be only executable by others. The contents of an executable only directory cannot be listed, but the files inside it can be read (if the permissions of the file allow it). It is important that the directory can be executable in order to allow static content (e.g. .html files) inside it to be read. Remember that directories you don’t want anyone to have web access to, should be 0770 (writable by the owner and group, or 0750 writable by the owner and readable by group). Such strict permissions should by applied to password files, php include files or databases files (such as SQLite, BDB, etc).
- Do the same for example user, but specify rfrc group instead.
chgrp -R rfrc .
chmod 2751 .
- Optionally modify umask in .bash_profile in user’s home to 007 to make all files created by this user have 660 permissions set by default. If you want that newly created files by accessible by the web, you need to manually setup it’s permissions to 664.
Now I can login as the user “example” and update the web-site in the ../example_www/example.org directory. There is one more setup needed. Because files copied from other accounts can have 644 permissions set instead of 664, you need a script which will update permissions to 664 or 660 to allow other group members modify such files.
