What permissions should my website files/folders have on a Linux webserver?

When deciding what permissions to use, you need to know exactly who your users are and what they need. A webserver interacts with two types of user.

Authenticated users have a user account on the server and can be provided with specific privileges. This usually includes system administrators, developers, and service accounts. They usually make changes to the system using SSH or SFTP.

Anonymous users are the visitors to your website. Although they don't have permissions to access files directly, they can request a web page and the web server acts on their behalf. You can limit the access of anonymous users by being careful about what permissions the web server process has. On many Linux distributions, Apache runs as the www-data user but it can be different. Use ps aux | grep httpd or ps aux | grep apache to see what user Apache is using on your system.

Notes on linux permissions

Linux and other POSIX-compliant systems use traditional unix permissions. There is an excellent article on Wikipedia about Filesystem permissions so I won't repeat everything here. But there are a few things you should be aware of.

The execute bit
Interpreted scripts (eg. Ruby, PHP) work just fine without the execute permission. Only binaries and shell scripts need the execute bit. In order to traverse (enter) a directory, you need to have execute permission on that directory. The webserver needs this permission to list a directory or serve any files inside of it.

Default new file permissions
When a file is created, it normally inherits the group id of whoever created it. But sometimes you want new files to inherit the group id of the folder where they are created, so you would enable the SGID bit on the parent folder.

Default permission values depend on your umask. The umask subtracts permissions from newly created files, so the common value of 022 results in files being created with 755. When collaborating with a group, it's useful to change your umask to 002 so that files you create can be modified by group members. And if you want to customize the permissions of uploaded files, you either need to change the umask for apache or run chmod after the file has been uploaded.

The problem with 777

When you chmod 777 your website, you have no security whatsoever. Any user on the system can change or delete any file in your website. But more seriously, remember that the web server acts on behalf of visitors to your website, and now the web server is able to change the same files that it's executing. If there are any programming vulnerabilities in your website, they can be exploited to deface your website, insert phishing attacks, or steal information from your server without you ever knowing.

Additionally, if your server runs on a well-known port (which it should to prevent non-root users from spawning listening services that are world-accessible), that means your server must be started by root (although any sane server will immediately drop to a less-privileged account once the port is bound). In other words, if you're running a webserver where the main executable is part of the version control (e.g. a CGI app), leaving its permissions (or, for that matter, the permissions of the containing directory, since the user could rename the executable) at 777 allows any user to run any executable as root.

Define the requirements

• Developers need read/write access to files so they can update the website
• Developers need read/write/execute on directories so they can browse around
• Apache needs read access to files and interpreted scripts
• Apache needs read/execute access to serveable directories
• Apache needs read/write/execute access to directories for uploaded content

Maintained by a single user

If only one user is responsible for maintaining the site, set them as the user owner on the website directory and give the user full rwx permissions. Apache still needs access so that it can serve the files, so set www-data as the group owner and give the group r-x permissions.

In your case, Eve, whose username might be eve, is the only user who maintains contoso.com :

chown -R eve contoso.com/
chgrp -R www-data contoso.com/
chmod -R 750 contoso.com/
chmod g+s contoso.com/

ls -l
drwxr-s--- 2 eve      www-data   4096 Feb  5 22:52 contoso.com

If you have folders that need to be writable by Apache, you can just modify the permission values for the group owner so that www-data has write access.

chmod g+w uploads

ls -l
drwxrws--- 2 eve      www-data   4096 Feb  5 22:52 uploads

The benefit of this configuration is that it becomes harder (but not impossible*) for other users on the system to snoop around, since only the user and group owners can browse your website directory. This is useful if you have secret data in your configuration files. Be careful about your umask! If you create a new file here, the permission values will probably default to 755. You can run umask 027 so that new files default to 640 (rw- r-- ---).

Maintained by a group of users

If more than one user is responsible for maintaining the site, you will need to create a group to use for assigning permissions. It's good practice to create a separate group for each website, and name the group after that website.

groupadd dev-fabrikam
usermod -a -G dev-fabrikam alice
usermod -a -G dev-fabrikam bob

In the previous example, we used the group owner to give privileges to Apache, but now that is used for the developers group. Since the user owner isn't useful to us any more, setting it to root is a simple way to ensure that no privileges are leaked. Apache still needs access, so we give read access to the rest of the world.

chown -R root fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 775 fabrikam.com
chmod g+s fabrikam.com

ls -l
drwxrwsr-x 2 root     dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

If you have folders that need to be writable by Apache, you can make Apache either the user owner or the group owner. Either way, it will have all the access it needs. Personally, I prefer to make it the user owner so that the developers can still browse and modify the contents of upload folders.

chown -R www-data uploads

ls -l
drwxrwxr-x 2 www-data     dev-fabrikam   4096 Feb  5 22:52 uploads

Although this is a common approach, there is a downside. Since every other user on the system has the same privileges to your website as Apache does, it's easy for other users to browse your site and read files that may contain secret data, such as your configuration files.

You can have your cake and eat it too

This can be futher improved upon. It's perfectly legal for the owner to have less privileges than the group, so instead of wasting the user owner by assigning it to root, we can make Apache the user owner on the directories and files in your website. This is a reversal of the single maintainer scenario, but it works equally well.

chown -R www-data fabrikam.com
chgrp -R dev-fabrikam fabrikam.com
chmod -R 570 fabrikam.com
chmod g+s fabrikam.com

ls -l
dr-xrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

If you have folders that need to be writable by Apache, you can just modify the permission values for the user owner so that www-data has write access.

chmod u+w uploads

ls -l
drwxrwx--- 2 www-data  dev-fabrikam   4096 Feb  5 22:52 fabrikam.com

One thing to be careful about with this solution is that the user owner of new files will match the creator instead of being set to www-data. So any new files you create won't be readable by Apache until you chown them.

*Apache privilege separation

I mentioned earlier that it's actually possible for other users to snoop around your website no matter what kind of privileges you're using. By default, all Apache processes run as the same www-data user, so any Apache process can read files from all other websites configured on the same server, and sometimes even make changes. Any user who can get Apache to run a script can gain the same access that Apache itself has.

To combat this problem, there are various approaches to privilege separation in Apache. However, each approach comes with various performance and security drawbacks. In my opinion, any site with higher security requirements should be run on a dedicated server instead of using VirtualHosts on a shared server.

Additional considerations

I didn't mention it before, but it's usually a bad practice to have developers editing the website directly. For larger sites, you're much better off having some kind of release system that updates the webserver from the contents of a version control system. The single maintainer approach is probably ideal, but instead of a person you have automated software.

If your website allows uploads that don't need to be served out, those uploads should be stored somewhere outside the web root. Otherwise, you might find that people are downloading files that were intended to be secret. For example, if you allow students to submit assignments, they should be saved into a directory that isn't served by Apache. This is also a good approach for configuration files that contain secrets.

For a website with more complex requirements, you may want to look into the use of Access Control Lists. These enable much more sophisticated control of privileges.

If your website has complex requirements, you may want to write a script that sets up all of the permissions. Test it thoroughly, then keep it safe. It could be worth its weight in gold if you ever find yourself needing to rebuild your website for some reason.

I'm wondering why so many people use (or recommend) the "other" (o) part of the Linux rights to control what can do Apache (and/or PHP). By setting this right part to something else than "0", you just allow the whole world to do something on the file/directory.

My approach is following:

• I create two separated users. One for the SSH/SFTP access (if needed), which will own all the files, and one for the PHP FastCGI user (the user the website will run as). Let's call these users respectively bob and bob-www.
• bob will have full rights (rwx on folders, rw- on files), so that he/she can read and edit the whole website.
• The PHP FastCGI process needs r-x rights on folders and r-- rights on files, except for very specific folders like cache/ or uploads/, where the "write" permission is also needed. To give PHP FastCGI this ability, it will run as bob-www, and bob-www will be added to the automatically created bob group.
• We now make sure the owner and group of all directories and files are bob bob.
• Something is missing : even we use FastCGI, but Apache still needs read access, for static content, or .htaccess files that it will try to read if AllowOverride is set to something else than None. To avoid using the o part of the rights, I add the www-data user to the bob group.

Now:

• To control what the developer can do, we can play with the u part of the rights (but this the note below).
• To control what Apache and PHP can do, we can play with the g part of the rights.
• The o part is always set to 0, so nobody else on the server can read or edit the website.
• There is no problem when bob user creates new files, since it will automatically belong to its main group (bob).

This is a recap, but in this situation, bob is allowed to SSH. If there shouldn't be any user allowed to modify the website (eg. customer only modifies the website through a CMS admin panel and doesn't have Linux knowledge), create two users anyway, but give /bin/false as shell for bob as well, and disable its login.

    adduser --home /var/www/bobwebsite --shell /bin/bash bob
    adduser --no-create-home --shell /bin/false --disabled-login --ingroup bob bob-www
    adduser www-data bob
    cd /var/www/bobwebsite
    chown -R bob:bob .
    find -type d -exec chmod 750 {} \;
    find -type f -exec chmod 640 {} \;

Note : people tend to forget that limiting the u (owner) rights is most of the time useless and insecure, since the owner of a file can run the chmod command, even the rights are 000.

Tell me if my approach has some security issues, because I'm not 100% sure, but it is what I'm using.

I think this config has a problem : when PHP/Apache creates a new file (eg. upload), it will belong to bob-www:bob, and bob will only be able to read it. Maybe setuid on the directory can solve the problem.

Given the google rank on the above excellent answer, I think there is one thing that should be noted, and I can't seem to leave a note after the answer.

Continuing with the example, if you plan on using www-data as owner and dev-fabrikam as group with 570 permissions on the directory (or file), it is important to note that Linux ignores setuid, so all new files will be owned by the user that created them. This means that after creating new directories and files you will have to use something similar to:

chown -R www-data /newdirectory/
chmod -R 570 /newdirectory/

In Ubuntu 12.04 for Rackspace OpenStack, I had an odd issue where I could not get permissions 570 to work until I rebooted the server, which magically fixed the issue. Was losing hairs at an increasing rate over that seemingly simple issue....

I going with this configuration:

1. All directories except uploads one set to owner root and group root, permissions to 0755.
2. All files set to owner root and group root, permissions to 0644.
3. Uploads directory set to owner root, group www-data, permissions to 1770. The sticky bit doesn't let group owner to remove or rename the directory and files inside.
4. Inside uploads folder a new directory with www-data owner user and group, and 0700 permissions for each www-data user that upload files.
5. Apache configuration:

Deny AllowOverride and Index in uploads directory, so that Apache doesn't read .htaccess files, and Apache user can't index the content of uploads folder:

<Directory /siteDir>
   Options -Indexes
</Directory>

<Directory /siteDir/uploadDir>
   AllowOverride none
</Directory>

6. php.ini configuration:

open_basedir = /siteDir:/tmp:/usr/share/phpmyadmin
post_max_size = 5M
file_uploads = On
upload_max_filesize = 3M
max_file_uploads = 20

With this configuration, the www-data user won't be able to get inside directories other than siteDir/ /tmp and /usr/share/phpmyadmin. Also you can control the maximum file size, the maximum post size and the maximum files to upload in the same request.

When you have a FTP user called "leo" need to upload files to example.com web directory and you also require your "apache" user to be able to create uploa-files/sessions/cache files in cache directory then do as follows:

This command assigns leo as owner and group as apache to example.com, apache user is a part of group apache so it will inherit the permissions of apache group

chown -R leo:apache example.com

Another command which insures right permission and fulfill security concerns as well.

chmod -R 2774 example.com

Here first number 2 is for directory and insures each new file created will be remain in same group and owner permissions. 77 is for owner and group means they have full access. 4 is for others mean they can only read trough.

following is helpful to understand permission numbers

Number  Octal Permission Representation
0   No permission
1   Execute permission
2   Write permission
3   Execute and write permission: 1 (execute) + 2 (write) = 3
4   Read permission
5   Read and execute permission: 4 (read) + 1 (execute) = 5
6   Read and write permission: 4 (read) + 2 (write) = 6
7   All permissions: 4 (read) + 2 (write) + 1 (execute) = 7

IMO one has to take into account:

• do you trust a process which reads your files? eg. PHP?

Let's assume you have a server which various data under user 'test'.

The 'test' user has there:

• his data in $HOMEDIR
• his mail in $MAIL
• his data for web in /var/www/test

Now let's think about:

• a web app runs under test user (PHP-FPM) - it can delete any of his files!
• a web app runs under test group (PHP-FPM) - it can delete any of his files where directory has 'w' for the group and can modify any file which has 'r' for the group; and it could still read them - your ssh keys for example!

Let's assume PHP is buggy, and it is, do you trust its open_basedir? Do you chroot your PHP process? What is you don't, do you want it does crawls through all filesystem?

Your web app process, eg. PHP-FPM, then should:

• be restricted to specific path via chroot
• should not run under data owner's primary user or primary group permission

Thus you can do:

• test user is: test:test
• test user is in a secondary group eg. test-www
• a web app (PHP-FPM) runs under test-www:test-www
• test user if he wants that the web app can read his files will do: chmod u=rwX,g=rX,o= /var/www/test/public
• test user if he wants that the web app can write into his web data path: chmod u=rwX,g=rwXs,o= /var/www/test/public/upload (thus the app will create new files as: test-www:test-www - it will have test-www group because of setgid on the directory!)

Thus, if the web app process would be bogus it would just read specific files which would have group read, and it would be able to write to upload dir only. I would strongly recommend to have that upload dir on a filesystem with noexec,nodev,nosuid mount options and have constant monitoring for any new bizzare files in that directory, plus also monitor any new processes under test-www uid.

On Linux one could use ACL to better tune permissions. If more than one human should be to upload web data, it would be better to split human account from the account used to upload web data files, ie. to create new account eg. test-upload, and test user would manage ssh keys to restrict which human could ssh/sftp there. sshd_config knows ExposeAuthInfo options thus it can be configured to log which ssh key was used to upload the data.

I really doubt most webhosting services care about privileges separation, when they write 'secure' without any info what you get, I would say they lie.