Pubilc_html\WordPress Ownership and Permission Question

Linux doesn't care whether the files are in /srv/www or /home/user, as long as Apache knows where to find them. Lunux only cares about the permissions. If you want a file or directory to be writable by Wordpress, the user that runs Wordpress must have write permissions on that file or directory. This means one of the following:

1) The directory/file is 755/644, and owned by the user who runs Wordpress.

2) The directory/file is 775/664, and the user who runs Wordpress is in the group which the directory/file belongs to.

3) The directory/file is 777/666, and this is usually a bad idea.

You can accomplish 1) by using suexec+fastcgi. You can google for tutorials on how to make Apache run as a different user depending on the domain. This is probably the most secure way to run multiple sites on the same server using Apache & PHP, but it's quite a bit of hassle.

You can accomplish 2) by adding www-data to the user's group. This is a little tricky to set up properly, but it works pretty well as long as open_basedir restrictions are also set up properly. I sometimes use this method if I don't want the hassle of suexec+fastcgi and if I have reasonable trust in the quality of my webapps.

BTW, if this Wordpress the only site on your linode, you might as well dump Apache and try lighttpd or nginx. It's often easier to set up FastCGI with those servers. There are plenty of tutorials out there, too.

Thanks for the good directions hybinet, I think the second option is the most realistic one at the moment for me. The first option, as you noted and from what I've read, involves quite a bit of configuration. It sounds like an option I may consider in the future though. As for the second option, I've looked into it and correct me if I am wrong but would go as follows…

• Change ownership of the files and directories to MyUser and add the user who runs WordPress to MyUsers group

• Expand directory permissions to grant MyUser's group write access (775/664)

• Use open_basedir restrictions to exclude php execution from certain directories where it is not explicitly required.

  AllowOverride None

phpadminflag engine off

phpadminvalue open_basedir none

If I understand the security goal correctly, this sounds like a fairly secure setup as long I keep WordPress up-to-date and continue to be cautions with plugins by checking their source code before installing.

In regards to using lighttpd or nginx instead of Apache, I agree Apache should be my last choice. I went with Apache because basically, I had never set up anything besides a localhost install of XAMPP on a windows box before last week. Jumping into the most documented solution, that allowed me to keep my .htaccess files, seemed like the safest bet to get rolling.

open_basedir is for preventing one site from messing with another, not for protecting files within the same site. The "775 + Apache in the group" setting means that Wordpress on site A, running as the Apache (www-data) user, can write to any file on site B which has group write permissions. That would be the case if you have two or more Wordpress sites on the same server. (After all, all those files are writable by the Apache user.) That's not what you want to allow; you only want Wordpress to be able to auto-update its own files, not another site's files.

open_basedir = /srv/www/this.site.com:/tmp

This restricts PHP to its own home directory and /tmp (which is a common location used for file uploads and the like). If you need to allow additional locations, use the colon ( : ) to separate the entries.

A lot of people believe that open_basedir is a broken security feature, and it actually is a nasty hack. But it's the still the best protection you can have while running PHP as the Apache user (www-data).

Thanks again for the clarification hybinet, that makes a lot more sense now. I've gotten it all set up and it appears to be working (no errors in my logs).

I see why many think using open_basedir is a broken hack as when you search on any forum the first 3 pages of results are people having problems with it. It is still going to be supported in php6 though, so obviously it still serves a purpose for many admins out there.