What are the most appropriate system permissions for sites on shared hosting?

Question

Although the Drupal site goes into great detail about permissions and security, there are only vague/unclear references to shared hosting. From a Drupal point of view, what is the most secure set-up (ownership and permission levels) for a site on shared hosting?

As an example of the kind of info I'm looking for, WordPress suggests the following shared hosting settings:

• All files should be owned by the actual user's account, not the user account used for the httpd process.
• Group ownership is irrelevant, unless there's specific group requirements for the web-server process permissions checking. This is not usually the case.
• All directories should be 755 or 750.
• All files should be 644 or 640. Exception: wp-config.php should be 600 to prevent other users on the server from reading it.
• No directories should ever be given 777, even upload directories. Since the php process is running as the owner of the files, it gets the owners permissions and can write to even a 755 directory.

Answer 1

Hosting options

Hosting options for a website site is generally one of the following:

• dedicated server
• virtual private server (VPS)
• shared hosting

With a dedicated server, only one site is hosted on a physical computer, and the configuration is as secure as the computer itself.

With a VPS, your software runs on the same physical computer as other users' virtual machines. However, it is functionally equivalent to a dedicated server. Most important, a VPS has the privacy and security of a dedicated server.

With shared hosting, your web site resides on a file system shared with other users. This, unfortunately, makes it less secure than when it is running on a dedicated server or VPS. The rest of this article discusses the security of a WCMS in shared hosting environment.

Environment

A shared hosting environment can be regarded as consisting of a web server, a file system, a settings file, a database, and some users.

In the following examples, it is assumed that the owner account is "tom", and that the settings file (holding database credentials) is named "settings.php".

The web server process may run with the user permissions of the owner account "tom", or with group permissions of the group "www", depending upon the configuration.

Also, a standard Gnu/Linux or Unix environment is assumed, and it is assumed that the reader understands the Unix access control system with separate read (r), write (w) and execute/access directory (x) permissions split into three blocks (user, group, other).

Before I go on to discuss specific settings, it may be helpful to list the conditions we want to satisfy:

1. For a web-site to be operational, the web server must have read access to all the files that make up the site, and access directory access to all the directories that make up the site.
2. For secure operation, web server must not have write access to any of the files it handles.
3. For secure operation, a web script run by a rogue user must not have read access to the files owned by another user.
4. For the owner to work on his own site using the CLI, the user must have read and write access to his own files.
5. To protect the files from being accessed by other users using the CLI, the "other" block should have no permissions set.

Unfortunately, on a shared host, you can only have 4 out of 5. I know of no way you can satisfy all five conditions on a shared host.

As far as I know, two different configurations are used by shared host providers. Both are discussed below, along with the permissions to use to best protect files and directories, and what condition the configuration fails to satisfy.

Config 1: Web server is running as owner

This is AFAIK the most widely used configuration. The web server is running as owner of the files. This means that a rogue user cannot use his web server user to run a script to read another user's files. This type of configuration also protects users from each other in the CLI.

However, it also means that we can't have separate permissions for the owner and the web server. To satisfy condition 2 with this type of setup, you need to restrict write permissions for the owner in order to prevent write access for the web server to everything except the upload directory.

Permissions:

Directories:  500 r-x --- --- tom.tom
Files:        400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.:  700 rwx --- --- tom.tom

Unfortunately, this means that condition 4 cannot be satisfied. I.e. the site cannot be maintained through the CLI. The owner will be constrained to use some sort of web-based dashboard to access the site (my recommendation is that the owner maintains a copy on some staging server where he has unrestricted access, and mirror changes made on the staging server to the shared host).

Config 2: Web server is running as a member of the www group

This configuration is used by some (IMHO) less professional providers of a shared host solution. The web server is running as a member of the www group, and is given the required read access through the group block:

Permissions:

Directories:  750 rwx r-x --- tom.www
Files:        640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.:  770 rwx rwx --- tom.www

These settings have the advantage of giving the owner full access to his files through the CLI, and restricts the web server to read access only.

However, it also fails to satisfy condition 3. I.e. it allows a rogue user on the shared host (or a hacker that as compromised the site of another user sharing the host) to run a script to read any file that can be read by the web server. This gives the rogue script access to the file settings.php with the database credentials, which makes it trivial to completely take over the site.

My recommendation is to avoid this type of configuration.

Addendum: How dangerous is it to use a shared host?

I certainly would not put anything sensitive, such as credit card numbers or medical records, on a shared host. But shared hosting is cheap, and there is an attraction in that. I use shared hosting myself for several of my sites. I haven't been hacked yet, but I know that the risk exists and I am prepared for the day when it happens. If I am hacked, I will simply delete everything on the shared host, and reinstall the site from a mirror copy I keep on a secure staging server.

With "config 2", the main problem is the others. If some other website that you share the host with gets compromised, your website is also lunch. Making security depend upon another party you don't know and have no control over is not a good idea. This is why my recommendation is to avoid "config 2"-type hosting arrangements.

With "config 1", you alone control your web site's security. This is better (in particular if you know what you're doing). But it is not fool-proof. Nobody's perfect, and if you goof up and your site is compromised, the attacker will have access to every file stored on that host that belongs to you. In other words, to minimize the damange when you're hacked, do not keep anything on that host that will cause harm if someone else gains access to it. In particular, do not keep your email on that shared host. There is usually tons of sensitive data in email, so you do not want it anywhere near a web server executing as "you".

And if your web applicaton is handling sensitive data, make sure your budget allows for a dedicated host or a VPS.

You may also want to see this guide to Securing file permissions and ownership at Drupal.org.