How you you manage your web users, groups and file system permissions??

kind of option 2. I have a user that owns the site. This user is just a regular user. The files directory, i.e., where the site writes files has permission 775 owned by <site-user>.www-data. The only issue I have is whenever some module creates files, like CTools, for example and it's owned by www-data.www-data and I do a drush cc all and PHP cannot unlink (delete) the file. Of course that's something that find is very useful for:

and similar for handling permissions.

There's a good discussion of this here: http://drupal.org/node/244924

The way I see it the goals are this:

1. Make all files non world-viewable. I don't see any reason that any code or data files would need to world readable in either a single user or multiuser enviroment. Generally code COULD be world-readable since anything sensitive should be separate from the code, but there are files such as db dumps that shouldn't be world viewable.

2. Code files should not be writable by the web server. Your php-fpm process shouldn't be able to overwrite any drupal code, whether it's core or modules. That's a security risk. So all code should be owned by someone other than the user that runs the php-fpm process. So for our examples, the user will be brian (although I use a dedicated user www-admin, see below)

3. Code files need to be readable by the web server. So if we run php-fpm as user www-data then all code should have a group of www-data and be group readable. Respecting 1 and 2 above, then directories should be 750 and files should be 640. All code files should be brian:www-data.

3. Your public and private "files" directories need to be www-data writable. That applies whether your private directory is inside your public one or completely outside the web root. So files directories should be brian:www-data because the php-fpm doesn't need to delete that directory, but the directory should be 770 so that the php-fpm process can create files and directories inside it.

4. Your php-fpm generated files should be writable by the www-data user since they may need to be purged from the web site. As a practical matter, you need to expect anything under /sites/default/files to be www-data:www-data and 660. Examples would be css files which get purged from pressing the clear cache button and imagecache automatically purging old cached images.

Now that's all well and good. And that article has some commands to fix stuff that way. I use the numbers so I do:

and that will change every file ownership and make no file world readable.

Then you need to fix the "files" directory with this:

and that allows php-fpm to write in the files directory and then changes the ownership of every file in the files directory to www-data so that php-fpm can also purge those files as it likes.

Then you have the drush problem. You don't want to run drush as root because stray drush code could screw your whole system. You want to limit drush to only web related files. But, drush needs to be able to write code files for such things as updating modules. So the easiest thing is to run drush as the owner of the files. Then drush can move an old module to the backup_dir and replace it with the new version.

As perusio pointed out above, that means that drush user would not be able to write the files written by php-fpm as www-data:www-data. So for that you can add the drush user to the www-data group. By default, php-fpm is going to write its files as 664, group writable, so adding the drush user to the www-data group will allow things like "drush cc all" to purge your old css files and such.

As stated, it's often required that you go back and fix permissions. Your typical user, "brian" in this example, writes files by default as 644, world readable. So when you do a "drush dl imce" you get an imce directory that's brian:brian and 745 on directories and 644 on files. This doesn't break your site because the files are world-readable, but it's less than ideal. You'd rather that the imce directory be immediately brian:www-data and 750 on directories and 640 on files.

Another example of bad drush permissions is when you do a sql-dump the files are written as 664 if you're using brian as the drush user. Now hopefully they're in a private directory that is 750 at least so not world-readable since the world cannot traverse the parent directory, but it'd be better if the sensitive files themselves were not world-readable.

My solution for a single user environment is to create a www-admin user that writes files as www-admin:www-data and 750 and 640 by default. Instead of brian in the commands above, you'd substitute www-admin as the owner of all the code.

This is how I set up the new user:

1. creates a new user that uses www-data as its group
2. puts a umask in its shell .profile so that it creates non-world-readable files and directories
3. creates a new www-admin group and adds your regular user to that group
4. allows that group to do things as the www-admin user without a password
5. creates an alias for the regular user so drush commands will be run as the special drush user
6. and then copies .ssh credentials to the new www-admin user so that the admin user can do fancy stuff with syncing various machines

Then when you do a "drush dl imce" you get a nice imce directory that is already www-admin:www-data and 750 and 640. Also when you do a sql-dump you get the same. Fewer permission-correcting scripts are necessary.

It also separates out the need to use root for any web admin. If you need to delete a directory you can do "sudo -u www-admin rm imce". If you need to muck around as the www-admin user you can do "sudo su www-admin". You can then leave your sudo to the root user password protected.

This doesn't solve the problems where you have multiple users.

Also it doesn't solve the problem noted in the article that if you run drush to create something, then the php-fpm cannot then delete that item. But that is a natural consequence of the security settings. You COULD let the php-fpm process delete files created by the drush user, but you don't want to. Until drush can do different permissions for different tasks, that can't be solved.