Support » Fixing WordPress » Understanding file permissions and ownership

  • I’ll start off with the question and then the explanation of why I’m asking.

    Question:
    Is it a good practice to set the apache account as the owner of the WordPress files? What’s the best solution to resolve the issue described below?

    Explanation:
    I’m running a dedicated server with WordPress installed. The httpd (Apache) process runs as the “Apache” user. The owner of the files is my user account and the group owner is the “apache” group that contains the apache user. I set permissions to 755 and 644 on everything but the wp-content directory which I changed to 775 and 664. It turns out that these permissions are not sufficient. When trying to perform certain tasks, such as deleting a plugin, I’m prompted for FTP creds, which means that WordPress cannot gain the appropriate access to the file system. I tried setting everything to 777 and it still didn’t work. In one last attempt, I tried setting the apache user as the owner of the files and it finally started working. After a bunch of troubleshooting I found that when WordPress creates a file in the wp-content directory the permissions get set to 644. Since apache is not the owner of the file it cannot delete nor modify the file(s). So now I know why it’s failing and I don’t really want to get into configuring a method of getting the process/scripts to run as a different user account. Keep in mind that these are dedicated servers in a corporate environment, not shared hosting…if that matters. I just want to be sure I’m not building servers that are overly vulnerable to attacks.

Viewing 6 replies - 1 through 6 (of 6 total)
  • Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    Is it a good practice to set the apache account as the owner of the WordPress files?

    No, that is a security risk.

    What’s the best solution to resolve the issue described below?

    You have two options:

    1. Live with it. The asking-for-credentials thing is actually a security feature. It’s doing this so that it can update files as the correct owner of the code (your account) instead of leaving the files to be owned by the owner of the PHP process (“apache”).

    2. Use a setuid method to run the PHP process. Some explanation is needed.

    First, note that this has nothing to do with the permissions on the files. Even if everything was 777, WordPress still would refuse to update the files because of the ownership.

    Your files are owned by your user account (“user”). The Apache process runs as another account (“apache”).

    When an http request comes in, Apache fires off a PHP process. This process runs under the “apache” account. Now, the “apache” user can read your files, so the PHP process can read them and run them. All is well so far.

    But if the PHP process writes any files, those files will be owned by “apache”, not by “user”. For things like image uploads, this isn’t a very big deal. For PHP and other executable code, it kind of is a big deal. Those files need to be owned by your user account, not by “apache”, because “apache” is the process that the whole world can cause to do things.

    WordPress is detecting that it’s owned by “user” but the process is “apache” and so it will refuse to write the files that way, and that’s why you get the FTP credentials screen. Because with those credentials, WordPress can make a connection back to itself and through that, it can write files as “user” instead of as “apache”, thus updating itself properly.

    On a dedicated server, this is the most secure option. If somebody does “hack” your server, then the code they are likely to be able to write will be owned by “apache” and only have access to things that “apache” can access, not to things that “user” can access.

    On a shared server, another option is called “setuid” or “suPHP” or similar. Essentially, when the PHP process executes, it looks at the owner of the PHP file it’s running, and sets its own owner to be the same. Thus, Apache runs as “apache”, but PHP runs as “user” when it executes code owned by “user”. This is more secure for a shared server, because it ensures that the PHP process can not access files from other accounts on the same hosting. If a site is hacked, the hack is limited to that user account, and not to others.

    Now, in this setuid case, WordPress sees that it’s owned by “user” and the PHP process is running as “user” so it can write the files directly, and thus no FTP credentials are needed.

    Your best option on dedicated hosting, where you are the only user, is to live with it and put in the credentials when asked. Remember, the “web” door is one the whole world can access. If you do get hacked, you want to limit the ability of that hacker to infiltrate the system further. Having them only able to do things as “apache” and not as “user” is one limitation. Not a strong one, admittedly, but still. Defense in depth, and such.

    Thanks for the explanation, it’s very helpful in getting this figured out. I was trying to avoid installing an FTP daemon on the server due to security issues with that as well. I’ll keep playing around with it. I setup ftp on a WordPress dev server while troubleshooting the issue but I couldn’t get WordPress to connect even though I was able to connect using the ftp client from the server itself.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    WordPress also supports using SSH for updating instead of FTP, if your PHP Installation has the ssh2 extension installed in it.

    Thanks, I’m actually reading about that now.

    That’s slick! Added php-pecl-ssh2 and now I have the SSH2 option to choose from. Just gotta figure out the SSH keys now.

    Moderator Samuel Wood (Otto)

    (@otto42)

    WordPress.org Admin

    I wrote an answer to that recently on the StackExchange site that you might want to give a read:

    https://wordpress.stackexchange.com/questions/157931/why-does-wordpress-still-not-support-sftp/157942#157942

    Thanks again Otto. I got the SSH2 option to work but we also have a couple Joomla sites, which this doesn’t seem to be an option for. I have since got SuPHP working and think I’m going to go that route. Although this isn’t a shared server it seems to be how these CMS’s like to be configured.

Viewing 6 replies - 1 through 6 (of 6 total)
  • The topic ‘Understanding file permissions and ownership’ is closed to new replies.