1

I've been doing some research on file permissions as of late, as my WordPress installation on my VPS doesn't have write access.

From what I've heard it's very dangerous to make the apache user the owner of your WordPress files, as apache can then do whatever it wants.

The WordPress Codex says:

"All of your WordPress files must be either owner writable by, or group writable by the user under which your Apache server executes."

http://codex.wordpress.org/Updating_WordPress

That's great, but I've also heard talk of running your WordPress install as the FTP user:

If WordPress is running as the FTP account, that account needs to have write access, i.e., be the owner of the files, or belong to a group that has write access.

http://codex.wordpress.org/Changing_File_Permissions

Any ideas on the best way to set this up? Is it not a bad idea to have the WordPress files owned by the apache user? I feel like it is...

Improve this question
7
  • best way for what? It is a little hard to understand what is the question here. The codex have suggestions and requirement on how you should setup things and that is the best way to do it otherwise it would not have been in the codex (codex can be not clear or incomplete but is almost never wrong)
    – Mark Kaplun
    Commented Dec 21, 2013 at 20:00
  • I think a lot of people who are experienced devs don't have experience developing for people running on shared hosting @MarkKaplun, and so some of the codex stuff throws them off. When I started with WordPress, wrapping my head around the way it handles ajax and the issues that arise when you write code that's going to be run on a bazillion different server configs versus something that you or someone that you know and trust configures were the big hurdles.
    – Andrew Bartel
    Commented Dec 22, 2013 at 8:27
  • @AndrewBartel no, IMO people who never worked on unix (or modern windows) in an environment with multiple users don't understand file permissions, and I agree that it is complex stuff to understand, especially its various implications even without trying to add one line of code.
    – Mark Kaplun
    Commented Dec 22, 2013 at 11:08
  • Yes, I agree. I'm honestly brand new to this, I've been using shared hosting for a few years, and thought that moving to a VPS would challenge me to learn something new.
    – Noel Forte
    Commented Dec 22, 2013 at 18:02
  • @NoelForte, to give a good answer to your question (otto's was relatively general) you need to know how much trust you give in the users that will have access to the server and what kind of services you want to give them (do you need to create users for then?). In the trivial case where you are the only user and you sure all your code is secure you can just do 777 on all directories (only in theory, don't actually do that)
    – Mark Kaplun
    Commented Dec 22, 2013 at 18:18

2 Answers 2

Reset to default
1

Your files should be owned by your account. Period. They should not be owned by the "apache" user. This is insecure.

The files may need to be readable by the apache user. The recommended permissions are 755 for folders and 644 for files. With the exception of the wp-config.php file, which should be set to the lowest permissions that work. This would be 640, usually.

The wp-content folder and the uploads folder may need more permissive permissions for media uploads to work.

If the webserver is running as a different user, then WordPress will detect this, and when you try to do an upgrade, it will ask for your FTP information. Then it will do the update via FTP. By getting your information, it can log in as you and thus upload your files.

If you don't have FTP enabled on your server, you can configure WordPress to use SSH methods instead. This is a bit more complex and not common.

If the webserver is running as a different user, but using a "setuid" method, then it will automatically run the PHP files under your user account instead, and then it will be able to update directly. This is because a setuid method will change the process run as the userid of the files. This is more common on shared hosting, because it is more secure in such cases.

Some setuid methods that are used are "mod_suphp" or "FastCGI with suexec".

Regardless, you need to own your files, not the webserver.

Improve this answer
3
  • Hey @Otto, thanks for all the info. Personally, would you recommend running modules such as mod_suphp or suexec on a machine that isn't shared by anyone else? I've heard that this isn't always the best move on machines that are used only by one person. Thanks again for all the info; huge fan of your site!
    – Noel Forte
    Commented Dec 22, 2013 at 5:58
  • If the machine is not a shared server, then yes, using setuid methods would be less secure. Security is relative to the circumstances. You could set it up with its own SSH key to use SFTP for updating instead.
    – Otto
    Commented Dec 23, 2013 at 12:15
  • Finally, I'm assuming that .htaccess will need to be set to be writable by the server so that permalinks can work properly. I'm also assuming that this stuff should also be set to be group-writable so that the user account owns it, but WordPress can write to it. Would you consider a VPS to be a shared server, or would you treat it as a standalone device?
    – Noel Forte
    Commented Dec 24, 2013 at 1:25
-1

what does it matter who wordpress is owned by as long as they have chown and chmod - probably best to have admin name be something other than apache, root, admin etc...

for example,

chown username -R /var/www/website/

chmod 775 -R /var/www/website/wordpress/wp-content

Improve this answer
1
  • 1
    The problem arises on shared hosting where if everything is owned by apache, nobody, etc, all of a sudden you can write to other installations on the same install. If you're running your own server then hey, do whatever you want, but if you're developing for the greater user base, that's the kind of stuff you need to take into account.
    – Andrew Bartel
    Commented Dec 22, 2013 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.