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.
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-pubusermod -a -G www-pub usera## must use -a to append to existing groupsusermod -a -G www-pub userbgroups usera## display groups for userChange the ownership of everything under /var/www to root:www-pub
chown -R root:www-pub /var/www## -R for recursiveChange 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
-Rrecursive 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
umaskline at the bottom of/etc/profilein my case) means files created by one user will be writable by other users in the www-group without needing tochmodthem.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!
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/
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.
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:
Or you can do it based on some shared group:
And perhaps you want to keep your Apache user as read-only
Man pages:
Tutorial
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_keysfile 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.