WordPress.org

1. ssteiner
   Member
   Posted 1 year ago #

   The Codex entry at: Changing File Permissions seems to contain conflicting instructions:

   All files should be owned by your user account on your web server, and should be writable by your username.

   and:

   NOTE: For the Automatic Upgrade/Install of Plugins/Themes and WordPress Upgrades, No special permissions need to be set. All WordPress files should remain owned by your user account (the user account the httpd runs as)

   Owned by my "user account" and owned by "the user account the httpd runs as" is contradictory. My user account doesn't run the httpd server, the user "nobody" does. A special restricted user, be it named nobody, www-data, etc., is used to run the web server on any properly set up Linux type server.

   It *seems* like all files should be owned by the web server user, but this makes it difficult to *edit* files as your regular user via (S)FTP without doing group tricks and
   allowing group write.

   Could someone who knows the correct information take a couple of minutes and disambiguate the Codex? I'd be happy to do it, but I don't want to send other people on a similar wild goose chase.

   Thanks,

   S

2. Emil Uzelac
   Member
   Posted 1 year ago #

   One of the ways would be to install http://wordpress.org/extend/plugins/wp-security-scan/ plugin.

   This plugin will automatically tell you about the current file permissions and in the case that they're not correct will also give you proper permission modes as well.

   Emil

3. ssteiner
   Member
   Posted 1 year ago #

   Thanks!

   I'll do that.

   My point was that the Codex itself offers contradictory advice and should be corrected.

   I wonder where the plugin author got the information they used to determine "not correct" permissions.

   It would be pretty straight-forward to write such a plugin, but with conflicting information from the canonical source, how would you know if it was right?

   Thanks,

   S

4. Emil Uzelac
   Member
   Posted 1 year ago #

   This plugin is using WordPress information and just an FYI it was built by reputable WordPress developer. You can rest assure that it will be the correct one :)

   Cheers,
   Emil

5. mrmist
   Forum Janitor
   Posted 1 year ago #

   If you want the auto-update to work, then the files have to be owned by the user that the httpd process runs as. This may or may not be your user account.

   I've edited the Codex page slightly, but due to the many different configurations that are out there, it's difficult to be highly prescreptive with the information (without getting very deep into detail, at least).

6. Otto
   Tech Ninja
   Posted 1 year ago #

   If you want the auto-update to work, then the files have to be owned by the user that the httpd process runs as. This may or may not be your user account.

   No, that's incorrect. The files should be owned by your user account, not the web-user account (if it's different). Always.

   The WordPress updater runs a test to see if it can create files with the same ownership as the files are currently owned by. If it can, then it uses the "direct" method of upgrading. If not, then it asks for FTP credentials in order to be able to write files via that method (which will give them correct ownership).

   Files should ALWAYS be owned by the user account. Anything else is insecure.

   On shared hosting systems, having files owned by the httpd process account basically allows anybody else with a web account on the server access to modify your files. Not good.

   Shared hosting systems that know what they're doing tend to use a method called "suexec", which basically means that the PHP process changes its user-account to be running as the owner of the PHP files. Thus, if your files are owned by you, they run as you. This is considered more secure for shared hosting because if somebody hacks your site, then they only have your credentials, not credentials that allow them to access all other sites on the server. Thus, in this case, you want the files to be owned by you as well. In this case, "direct" upgrading works fine, since the php process is running as you, thus it can create files with your ownership properly.

7. stufuller
   Member
   Posted 1 year ago #

   Thanks all for getting into this with me!

   The two answers above, also conflicting, illustrate the difficulty I've been having.

   When the user account owns the files, as @Otto said, it does indeed ask for FTP credentials, and downloads and expands the archive properly into the /tmp directory.

   Then, in my experience, the update fails to be properly applied as the web server cannot copy the files from /tmp since it doesn't have write permission to the files since they're owned by the user (not by the webserver user).

   When the webserver owns the files, the automatic upgrade goes fine, but I'm concerned about the security issues.

   I am going to look at the permissions set by the http://wordpress.org/extend/plugins/wp-security-scan/ plugin and see which way it goes.

   But, how would I know if it were right, regardless of what it does?

   Again, this all points to the need for a canonical answer on the Codex that is thorough, detailed, and *correct*.

   Thanks all who have contributed to this thread.

   S

8. mrmist
   Forum Janitor
   Posted 1 year ago #

   No, that's incorrect. The files should be owned by your user account, not the web-user account (if it's different). Always

   Fair enough, I suppose for most environments that will be the case. I'm not sure that the Codex entry as it is now saying that the files should never be owned by the httpd process user is totally correct, though. ;)

9. stufuller
   Member
   Posted 1 year ago #

   @Otto -- that suexec link is the key -- it allows the web server to temporarily run as *you* which would make the second step of copying the files work.

   This is probably the missing link that leads to this confusion in the first place. According to the codex, "Shared Hosting with suexec" will allow an FTP-less upgrade, though I've yet to know all the pieces to try that out. Now I have enough info, and I own the servers, so I'm going to go do a few experiments.

   The codex also gives specific permissions for specific files in that case, so I can go even further.

   I'm hoping that the plugin mentioned above takes all of this into account (i.e. detecting suexec) and gives a *working* set of permissions that is as secure as possible.

   Again, thanks to all for your help with this. Hopefully the outcome will be a completely correct codex page and, even better, a security audit button right in WordPress.

   This is pretty fundamental stuff, obviously isn't easy to get right, and exactly the type of thing that *should* be automated and included in the product.

   Thanks,

   S

10. ssteiner
    Member
    Posted 1 year ago #

    This is the report given by the WP - Security Admin Tools:

    WP - Security Admin Tools

    Initial Scan
    WordPress version: 3.0.4 You have the latest stable version of WordPress.
    Your table prefix should not be wp_. Click here to change it.
    Your WordPress version is successfully hidden.
    WordPress DB Errors turned off.
    WP ID META tag removed form WordPress core
    No user "admin".
    The file .htaccess does not exist in wp-admin/.
    **WP Security Scan plugin must remain active for security features to remain**
    Future Releases

    * one-click change file/folder permissions
    * test for XSS vulnerabilities
    * intrusion detection/prevention
    * lock out/log incorrect login attempts
    * user enumeration protection
    * WordPress admin protection/security

    It doesn't seem that there is any check of file permissions in the current version though it does look like it's planned for a future release.

    S

11. ssteiner
    Member
    Posted 1 year ago #

    My mistake, there is another menu choice "Scanner" that does a top-level scan, and shows the file mode, but does not go deep into the tree or check ownership information.

    S

12. ssteiner
    Member
    Posted 1 year ago #

    So, here's the result:

    All files owned by myuser.

    Suexec enabled.

    File permissions correct as per WP Security Admin Tool (it only checks top level directory).

    -------------------

    Plugins can be deleted and installed after providing SFTP credentials.
    Reinstall of wordpress fails like so:

    Update WordPress

    Downloading update from http://wordpress.org/wordpress-3.0.4.zip…

    Unpacking the update…

    Verifying the unpacked files…

    Installing the latest version…

    Could not copy file.: /public_html/blog-2010-09-22/wp-admin/css/theme-editor.dev.css

    Installation Failed

    I'm going to go deeper into the file heirarchy to see whether I can figure out which permission setting is causing this failure, but I'm a lot closer (and I think, more secure) than when I just had the webserver user owning everything.

    Thanks, more to come, and I'll be blogging the final result soon.

    Thanks,

    S

13. Otto
    Tech Ninja
    Posted 1 year ago #

    It's trying to copy files to the wp-content/upgrade directory. Try giving that directory 777 to see if that helps.

    The actual copy over the existing files happens via the ftp methods.

14. ssteiner
    Member
    Posted 1 year ago #

    Thanks @Otto.

    I'm sure 777'ing will work, but the goal is to find the most restrictive permissions that still work.

    Since I've already fiddled with the permissions in various folders, I'm starting at the top again with a fresh Fantastico install, and writing a "Security Tightening" plug-in.

    Yes, I know the default Fantastico is not the best for various reasons, but that's kind of the point. Why would you need a security checker if it was already perfect out of the box?

    Looking through the existing plugins (all seven zillion pages of them), none of them really cover all the bases, and most of them don't have anything to do with securing the installation itself.

    I'm going to take everything I know so far, and produce as tight an installation as I can that still works.

    S

15. Otto
    Tech Ninja
    Posted 1 year ago #

    Well, what I meant was for you to see if making just the upgrade folder 777 would allow it to work. If so, then you at least know the cause of the issue and can adjust permissions downward to see what works and what doesn't.

16. ssteiner
    Member
    Posted 1 year ago #

    Understood.

    I really need this to be a one-shot, to lock down sites we sometimes get in pretty bad shape.

    That will certainly be something I will try.

    Thanks again,

    S

Topic Closed

This topic has been closed to new replies.