What's the best way of handling permissions for Apache 2's user www-data in /var/www?

Question

Has anyone got a nice solution for handling files in /var/www? We're running Name Based Virtual Hosts and the Apache 2 user is www-data.

We've got two regular users & root. So when messing with files in /var/www, rather than having to...

chown -R www-data:www-data

...all the time, what's a good way of handling this?

Supplementary question: How hardcore do you then go on permissions?

This one has always been a problem in collaborative development environments.

Solution 1

Attempting to expand on @Zoredache's answer, as I give this a go myself:

• Create a new group (www-pub) and add the users to that group

  groupadd www-pub

  usermod -a -G www-pub usera ## must use -a to append to existing groups

  usermod -a -G www-pub userb

  groups usera ## display groups for user

• Change the ownership of everything under /var/www to root:www-pub

  chown -R root:www-pub /var/www ## -R for recursive

• Change the permissions of all the folders to 2775

  chmod 2775 /var/www ## 2=set group id, 7=rwx for owner (root), 7=rwx for group (www-pub), 5=rx for world (including apache www-data user)

  Set group ID (SETGID) bit (2) causes the group (www-pub) to be copied to all new files/folders created in that folder. Other options are SETUID (4) to copy the user id, and STICKY (1) which I think lets only the owner delete files.

  There's a -R recursive option, but that won't discriminate between files and folders, so you have to use find, like so:

  find /var/www -type d -exec chmod 2775 {} +

• Change all the files to 0664

  find /var/www -type f -exec chmod 0664 {} +

• Change the umask for your users to 0002

  The umask controls the default file creation permissions, 0002 means files will have 664 and directories 775. Setting this (by editing the umask line at the bottom of /etc/profile in my case) means files created by one user will be writable by other users in the www-group without needing to chmod them.

Test all this by creating a file and directory and verifying the owner, group and permissions with ls -l.

Note: You'll need to logout/in for changes to your groups to take effect!

Solution 2

I am not entirely sure how you want to configure the permissions, but this may give you a starting point. There probably are better ways. I am assuming you want both users to be able to change anything under /var/www/

• Create a new group (www-pub) and add the users to that group.
• Change the ownership of everything under /var/www to root:www-pub.
• Change the permissions of all the folders to 2775
• Change all the files to 0664.
• Change the umask for your users to 0002

This means any new file created by either of your users should be username:www-pub 0664 and any directory that gets created will be username:www-pub 2775. Apache will get read access to everything via the 'other users' component. The SETGID bit on the directories will force all files being created to be owned by the group that owns the folder. Adjusting the umask is needed to make sure that write bit is set so that anyone in the group will be able to edit the files.

As for how hardcore I go on permissions. It completely depends on the site/server. If there is only 1-2 editors and I just need to keep them from breaking things too badly then I will go easy. If the business required something more complex then I would set up something more complex.

Solution 3

I think you may find POSIX ACL (access control lists) to be helpful. They allow a finer-grained permission model compared to the user:group:other model. I have found them to be easier to keep straight in my head since I can be more explicit and can also set the "default" behavior for a branch of the file system.

For example, you can specify each user's permissions explicitly:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

Or you can do it based on some shared group:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

And perhaps you want to keep your Apache user as read-only

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Man pages:

• setfacl
• getfacl

Tutorial

Solution 4

This question was asked again, and as discussed on meta, current best practices provides better approaches than there was available in 2009, when this was asked. This answer tries to give some current solutions for handling collaborative web development environments securely.

---

For a secure web server & collaborative development there's more than just the file permissions:

• Have separate user for every site i.e. don't serve all sites using www-data. This is important, as nowadays Apache is seldom serving solely static content files, but running dynamic web sites. This answer concentrates on PHP as it's the most common server-site language, but the same principles applies to the others, too.

  If you have a security problem on a single site, it can spread to every site that is running as the same user. An attacker can see everything the user sees, including database login information, and modify every site the user has write permissions to.

• Use SSH File Transfer Protocol (SFTP). While using FTP should be abandoned for security (as it sends both the passwords and the content in plain text), it's secure substitute SFTP also has a feature that is a perfect solution for collaborative web development.

  Once you have isolated the sites and one user per site, you need to give access to your web developers, what this question is all about. Rather than giving them the passwords for these site users – or access to the site files using their personal user accounts as originally suggested – you can use SSH keys for login.

  Every developer can generate keypair and keep the private key secret. Then, the public key is added to the ~/.ssh/authorized_keys file for every website user account the developer is working on. This has many advantages for managing the passwords and logins:

  • Every developer can have access to any number of web sites without the burden to remember or store all the passwords involved with the user-per-site arrangement.

  • No need to change & share the passwords every time someone leaves the company.

  • You can use very strong passwords or disable password based login altogether.

• Use PHP-FPM. It's the current approach for running PHP as the user. Create a new pool for every user i.e. one pool per every site. This is the best for both security and performance, as you can also specify how much resources a single site can consume.

  See e.g. NeverEndingSecurity's Run php-fpm with separate user/uid and group on linux. There are tutorials like HowtoForge's Using PHP-FPM with Apache on Ubuntu 16.04 that doesn't use PHP-FPM for increasing security through user separation, guiding to use a single FPM socket across the server.

View more solutions

Comments

[Zoredache]

Also see: What are the best linux permissions to use for my website?

[gacrux]

Possible addition - set cache/upload dirs that need to be written to by the webserver to www-data:www-data and 775.

[marcin naglik]

Would it work as well to add the users to the apache group instead of relying on 'other' permissions? If all you are doing is uploading files and those files need to be readable by apache a 3rd group only seems to be useful if you need to edit those files.

[Zoredache]

@Ursid, to keep things secure I generally I try to avoid giving the web server process the ability to write files in places it doesn't need to. I grant users the ability to write via the group permissions, if the same group was used by the web server, then any misbehaving script/cgi could trash anything under /var/www.

[Tom]

Any chance you can expand this a little @Zoredache? I grok the basic use of rwx bits, chmod, chown, adduser, usermod, but you've lost me with the extra first digit on the octal permissions, umasks and all that. Some sample commands illustrating your outlined approache would be greatly appreciated.

[Tom]

@Zoredache: please feel free to incorporate my answer into yours to expand it if you want.

[Trif]

On debian lenny, in addition to Tom's post, i had to modify /root/.bashrc umask also to 0002, or www-data won't have a proper umask by just editing umask in /etc/profile .

[signpainter]

In your first find command you have 27*55* and not 27*75*. I got stuck, heh.

[Zoredache]

@AlberT, Yes, that is true, I am assuming that isn't really much of an issue. It would take more then tweaking permissions to 2770/0660 to fix that. If you just modified permissions, and the server ran PHP or something, then one user could easily write a program to read the files of another user. You will not the question mentions collaborative development environments, which led me to assume he wants users to be able to see each others content.

[Sandokas]

That's the way ! +1

[Sandokas]

Using acl you can handle both security and collaborative-ness :)

[lnostdal]

the accepted anwer works great when dealing with local text-editors (nano running on localhost), but remote editors working via sshfs mounts (ubuntu, mac) seem to do stuff like change the permissions of files upon save -- or, on mac, saving/creating is not "permitted" at all

[aculich]

@Tom Great to see that you recommend using the findcommand for this. One small performance tip I would give if you have lots of files/directories and you are using GNU find is to use + instead of \; so that the command will operate on multiple files because "it is faster to run a command on as many files as possible at a time, rather than once per file. Doing this saves on the time it takes to start up the command each time." Also, it is easier to type since it doesn't need backslash.

[Gareth]

Current as of 2012-05-25 This is still the best way to do it. Marking as correct answer even though @Zoredache had the original solution but this is more verbose.

[sunnyrjuneja]

Tom, when I type find /var/www -type d -exec chmod 2775 {} + I get the error: find: missing argument to `-exec'

[Tom]

@SunnyJ. What OS? I've tested that in bash on Ubuntu and cygwin... Maybe try going back to \; instead of + and see if that helps you.

[sunnyrjuneja]

Ubuntu 12.04 and \; worked fine. Thanks!

[sunnyrjuneja]

Actually, when I type: find /var/www -type f -exec chmod 0664 {} \; I get: chmod: cannot access `': No such file or directory repeated over and over again. My OS is Ubuntu 12.04.

[Buttle Butkus]

@SunnyJ. try this (without the outer quotes): "find /var/www -type f -exec chmod 0664 '{}' \+" Try that. There is a space between the '{}' and the \+.

[Kevin Parker]

why we need to give permission for others to see and execute.

[Yarin]

@Tom- way to break it down, thanks. Just a note- I think "SETUID (4) to copy the user id" as included in your answer is wrong- SETUID is ignored when applied to directories in Linux/Unix - Ref

[Yarin]

ACL for the win +1... For more see serverfault.com/a/360120/41823

[Buttle Butkus]

I wonder if there's any performance downside for ACL vs basic permissions.

[Andrew Cheong]

How would handlers like PHP-FPM fit into this model? You'd have to run PHP-FPM as a user in the group www-pub? (Because it would need executable permissions, no?)

[Aleksandr Ilin]

@Zoredache if we weren't in a collaborative development env. we wouldn't want grant "the world" read right on web application source files: We would set file/dir owner to www-data, grant read+execute rights and block others/world? (chmod -R ug=rx,o= /var/www)?

[Tim Tisdall]

Instead of "2775" you may want to use "g+ws" so you just add "write" and "sticky" to the group permission and leave the rest. Likewise, replace "0664" with "g+w". Otherwise, if you have files that should be executable, you'll lose that setting on them. Or if you have files that shouldn't be "other" readable they'll become readable, etc...

[Ninj]

Unfortunately, ACL is too often missing on standard installations/distributions. It's a pain to compile kernel on every servers i manage, or worse, change filesystem sometimes. Plus you must be very careful when backuping files up, especially if you are switching servers. ACL is great but its current support is so low that i would recommend against it for anyone who doesn't have full control on everything on the server and surroundings. But +1 for pointing ACL out where it really makes sense!

[Gavin]

Why not have this agnostic group called www instead of www-pub? The -pub is confusing to me, because it makes it seem like it is only for the public/ dir in a project. Also, www is more concise, and shorter is cooler.

[dangel]

So I followed these instructions, but newly created files are showed to be owned by the user I'm signed in with, and now WordPress can't modify plugs\files

[Tom]

the purpose of this was to have any new files be owned by your user, but automatically be part of the group so other users can view/edit them.

[B. Shea]

Good answer +1 ; A note about changing the apache process read/write permissions (www-data for instance) to read-only for whole site (via setfacl or chmod - or both) -> This will obviously block all writes (plugin/module uploading/updating from browser side on most CMS for example). I believe many popular ones also only test for write access on user perm level not the group level. You can still update, but updates must be applied manually and any custom permissions for write folders (logs/temp/uploads/etc). Read-only is great security if your site works with it.. by and large most don't.

[Etienne Charland]

Setting the owner to www-data:www-data works but isn't ideal. However, by setting the owner to root:www-pub, Wordpress is unable to update. Both my local user and www-data are part of the www-pub group. What part am I missing?

[Kevin Chavez]

Would it be possible to expand on what the steps are to "Have separate user for every site" I am just learning basic server admin stuff I am not experienced. So going from say a default install of apache / nginx with php-fpm where the /var/www/ folder is created what steps should be followed to properly add the user, change file ownership (to the user?), and make sure apache / nginx / php-fpm can still read/execute those files? I am unclear on what group the new user should be a part of and what adjustments need to be made to the apache / nginx / php-fpm user/group settings.

[Esa Jokinen]

That would be a tutorial; that would be too lengthy for a Q/A site, and also not answering to the original question. The "Use PHP-FPM" section already has links to such tutorials.