Setting ownership and permissions for webserver directories

Never assign www-data to any group, especially not a group like sudo that can gain admin priviliges. If there's a major security flaw in WordPress or one of it's plugins, there's a chance that the priviliges from the assigned group could be used to compromised the rest of your system.

Don't assign www-data a full 7 for everything, for the same exact reason. Instead, do the follolowing:

chown -R www-data:sudo /your/web/site
chmod -R 570 /your/web/site/
chmod -R 770 /your/web/site/plugins/
chmod -R 770 /your/web/site/uploads/
chmod -R 670 /your/web/site/uploads/*

Replace the above as necessary. Notice that this assigns the number 5 (read/execute) to www-data for most of your site, and a 7 (read/write/execute) for plugins and uploads directories. The finally chmod allows read/write for the contents of uploads, as a security measure; directories, for some reason, need execute permissions to be accessed, while files don't – especially not ones being uploaded by your users.

One thing I'd like to point out -- assigning group ownership to sudo seems a bit overly redundant since anyone using sudo to modify stuff can modify anything that root can (which is everything on your server). All that does is allow anyone in the sudo group to modify stuff without using the sudo command. That could be a security risk, if only a minor one provided you can trust your admins.

I wasn't going to add the webserver user as a super user, as that would obviously be a very bad idea. I wanted to make sure that chmod -R www-data:sudo webservers wouldn't do anything like that. Plus what I was wondering is if assigning www-data as the owner of files under the /webservers directory allow files to be 770 instead of 777 but still writeable by the webserver.

Based on your example, it looks like assigning file ownership as chown -R www-data:sudo /path/to/directory would be ok. It also looks like 770 would be writeable by the webserver with that ownership. Then the files and directories that don't need to be writeable by the webserver could just be 570.

As for making the files owned by sudo, it would prevent the other admins from needing to use sudo with every command. I also trust anyone else who has admin access.

@Inquisitor Sasha:

Based on your example, it looks like assigning file ownership as chown -R www-data:sudo /path/to/directory would be ok. It also looks like 770 would be writeable by the webserver with that ownership. Then the files and directories that don't need to be writeable by the webserver could just be 570.

Sure. Anything served up by your web server should have either user or group ownership (or both) assigned to www-data, depending on your needs. Just keep in mind the order of the numbers if assigning group ownership.

Just remember my advice of using 670 for the contents of any uploads directory, since that allows things to still be read and written without being executed. One can never be too paranoid in securing a server.

@Inquisitor Sasha:

As for making the files owned by sudo, it would prevent the other admins from needing to use sudo with every command. I also trust anyone else who has admin access.

As long as you can trust them. Just pointing out the potential risk.

How do you set the contents of the directory separately? I think that for things like plugins that use PHP files, doesn't the webserver need the execute permission?

Remove the "-R" bit and specify the directory. "-R" stands for "Recursive", effectively "go through every file and directory possible under (and including) the one I specify".

Unless your http daemon works differently from mine, PHP files should not need the execute permission. The web server should be able to grab the PHP files and send them directly to the PHP interpreter. Think of it in terms of a shell script: while it is convenient to give shell scripts the execute permission then execute them directly, it is just as valid to type the shell name followed by the script (e.g.t "bash somescriptwrittenforbash.sh").

If your site works fine without giving execute permissions then it wouldn't hurt to not set the execute permission. Though in my opinion, this is a case where it really depends on your level of paranoia – as long as you don't set anything inside your uploads directory to executable, there shouldn't be any real danger to using the execute permission on PHP files, however there's nothing wrong with the "better safe than sorry" approach :wink: