3

I've attempted to set up my WordPress installation as recommended in the Codex's "Hardening WordPress" article. That is:

  • All files are 644, all folders are 755
  • Everything is owned by the user account
  • wp-content is writeable by the webserver account (it's 775 and group-owned by apache's account)

The Codex document says auto-update should work with this setup. But in practice, when I try to update (from 4.2 to 4.31), I get the usual permission error (inconsistent permissions on update-core.php).

If I temporarily change that file to be writeable by the webserver account, then the update gets past that step (and complains about permissions for a massive list of other files).

So as near as I can tell, it seems that auto-update can't proceed unless most of the files in wp-includes and wp-admin are writeable by the webserver process - which is exactly what the "hardening" article says to avoid.

Any guesses what the issue might be?

Improve this question

1 Answer 1

Reset to default
4

The point of hardening is to avoid the core files to be manipulated by external users (on shared hosting) and by the webserver (as it is the main source of exploits). Since the update runs via the webserver it is obvious that if you hardened your files against webserver initiated manipulation, the update will fail.

Most people probably get around it by using FTP to place the updated files (the update process imports a file from the update server and then uses the FTP protocol to actually write it instead of using the PHP file APIs). If you don't have FTP on your server then you are out of luck.

Secure settings are just not very friendly to updates, but IMO the cost of doing manual update (If you have SSH access then just use WP-CLI) once a month (if your plugins/theme are that bad) is worth the enhanced security.

Improve this answer
5
  • The codex doc says that auto-update runs as the account that owns the files, not as the web server account. Source link is now added to the question. Are those docs wrong?
    – fenomas
    Nov 5, 2015 at 6:48
  • It is hard to know in the codex when the writer misunderstands features or just a section is not written well. 644 means that only owner can write to the files, and since the update is triggered from the web server you will have to have the web server running under the same user for it to be able to directly use PHP to write to the files. If the web server runs under a different user it will fail. See also - wordpress.stackexchange.com/questions/5829/…
    – Mark Kaplun
    Nov 5, 2015 at 7:11
  • 1
    Whoa, now I'm confused. So (non-ftp) auto-update explicitly requires a configuration that various docs say you should not use? Or to phrase that more usefully, are you saying that a security-conscious user should want auto-update to not work, and should only update manually? (This is for a single blog on a VPS - no sharing, other users, suexec, etc.)
    – fenomas
    Nov 5, 2015 at 7:38
  • 1
    smart admins will never use auto update without testing that the update do not break anything, so while the ability of one click update is a nice things, the automatic one is BS (in the context of money generating site, for simple blogers on shared hosting the autoupdate is very good thing). In general you don't want the web server to have write access to anything which is not 777, but on shared hosting this kind of configuration might lead to users being able to read/write other users files which is bad, therefor the webserver needs to run as the user in that config.
    – Mark Kaplun
    Nov 5, 2015 at 7:59
  • Apache version 2.4 IIRC lets you specify a user under which a virtual host is being executed and that is probably what you will need to do if you don't like su_exec but still want automattic updates.
    – Mark Kaplun
    Nov 5, 2015 at 8:01

Your Answer

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

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