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?

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?

• permissions
• automatic-updates

1 Answer 1

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.