Permissions security scenarios for a web server

Question

Having /var/www/site.com owned by www-data:www-data with a 750 permission for directories and 640 for files, and having my user alexb added to www-data group, I found my self with permission issues when I try to pull new releases (git pull) to the testing environment.

So, right now, the only solutions that come into my mind, are the following:

• alexb:www-data ownership for /var/www/site.com with the same 750 and 640
• Stick to www-data:www-data, and a 750 and 640 permissions layout.
• Create a new user and group (staging-user:staging-group), give that new user real shell access and give assign the ownership of /var/www/site.com to them, with the initial 750 and 640 permissions layout, so that when I need to run so shell actions (git pull for example) I just switch user and do it.

Now, the questions are:

• Which is worst?
• Any big thing that I might miss?

Answer 1

Having /var/www/site.com owned by www-data:www-data

If www-data is also the uid your webserver runs as then you have a really insecure system. The webserver should only have read access (and execute for directories). If you do need to allow the webserver to write data then this directory should be ringfenced - and preferably outside the document root.

If alexb is the only account which needs write access then "alexb:www-data ownership for /var/www/site.com with the same 750 and 640" is a reasonable approach. However if you have multiple users who need write access, then the best solution is probably to create a new group with that access, allow the webserver read access as 'other' (775/664) but remember to set the user umasks approapriately (and enable the setgid bit on directory (2775)

Answer 2

xx4 in folder is more like having xx0, since "others" won't be able to see the contents of that directory. They would see the folder, but won't be able to do anything with it.

As the web server probably won't need write permissions, I would use the alexb:www-data with 750 (directories) and 640 (files), as this way reduces privileges for the web server but lets you use your personal user without worrying too much.

Apart from that, you should set all folders g+s permissions, so even in the case you create files as the user alexb, the web server will still have access through the group permissions (I'm assuming your user alexb does not have www-data as his primary group, so using that permission would keep the group id through the new files).

Just remember to set your UMASK acordingly (like 027), and do not use /var/www/site.com as the user's home directory.

Also, take into account security systems like SELinux (RedHat, CentOS, and such).

Answer 3

You are missing the option of ACLs. Linux has a very flexible ACL system that most people don't consider. I wrote up a blog post about this a while ago:

http://bryan.ravensight.org/2010/01/linux-acl-management-functions/

I generally set the ownership and group to the shell user and whatever group of interactive users that need to be able to update those files.

Then I use my grant-apache-read script to allow the webserver to access it:

source ~/lib/acl.bash; grantUserRead 'www-data' /var/www/site.come '*';

Two things you'll need to remember when trying this:

1. You need to make sure you have setfacl installed
2. Ensure that the correct user is being passed into the function
3. You'll need the ~/lib/acl.bash script
4. I also created a grant-apache-write script for cache and log directories