Sharing Write Access to a Web Directory for Multiple Users

In a multi-user environment, group permissions are the way to allow more than one user write access to the web server's document root. Just pick a name for the new group and apply it. It could go something like this:

That leaves any other directories under /var/www/ alone such as maybe /var/www/cgi-bin/ where write access might be further restricted. The two find instances show the slight difference in permissions needed for files and directories.

The setGID bit applied by chmod will ensure that files created in that directory or its subdirecvtories will have the same group as the parent directory. So any file create by any user that has sufficient privileges to write will have webmeisters as the group.

(Numerically those settings would be 2775 in octal instead of u=rwx,g=rwxs,o=rx in symbolic mode. Octal and symbolic modes are mostly interchangeable, but for one exception. Symbolic mode works even to unset the setGID bit, while the octal mode does not.)

Then add users to the shared group.

The accounts will be in the new group the next time they log in.

The user and group www-data are for privilege separation and should not have write access to anything in the web server's document root, except for special exceptions regarding individual files in certain content management systems (CMS) or similar packages. The concept involved is that of Least Privilege. That is to say the web server process should have only enough access to do its job, no more, no less. For most setups that means read-only access. Adding write permission anywhere for www-data breaks that security model and is likely to end up costing you in the medium to long term.

So the owner of the directories and files is not as important as long as it is not www-data, or whichever user and group the web server is running as. You could leave that directory as owned by your own account, as long as the group is set to the shared group.

umask

On many systems the umask defaults to 0002, so that means files created in the affected directories will be group writable. (umask is for the processes, such as the current shell, not the file system itself.)

There are two ways of ensuring group-writable files and directories, if the default is not sufficient.

umask option a - using the ACL

Using an Access Control List (ACL) is one way to force group write permissions regardless of the user's actual umask. The tool setfacl changes the ACL.

The -b clears any previous ACL for that directory before making the settings specified by -m, otherwise it can get cluttered when experimenting.

You can see what you have set with getfacl

If you have a large business or organization with many users, especially if some are in separate geographical locations, then you can consider the OpenAFS file system, which has a much easier way with ACLs but is harder to install.

umask option b - using the shell profile

Setting the umask in the shell profile is another way to allow group write permissions. However, it applies to all the account's activities in that shell session not just those in certain directories. A separate file in /etc/profile.d/ is better than editing /etc/profile. If they are using bash, ksh, or zsh, then put a file in /etc/profile.d/ with a name you will recognize and have that contain the 'umask' setting. It will set umask for everyone with the main shells: bash, zsh, and ksh. The default is bash. It is always possible for the user to modify their own umask if even only for their current session.

(Comments and corrections welcome.)