4

Is there a way to allow WordPress to automatically update while still using hardened permissions?

It seems the recommended security setup for WordPress is to use hardened permissions, which are mostly achieved using the permissions given in this answer. However, these permissions result in WordPress not being able to automatically update, or use update through the administrator web interface, resulting in an error:

Downloading update from https://downloads.wordpress.org/release/wordpress-x.x.x-partial-x.zip…

Unpacking the update…

The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php

Installation Failed

By allowing the web server to update update-core.php we violate the hardened permissions (as far as I can tell). Unfortunately, without automatic updates, we also have the problem that we don't get automatic security updates, which leads to another security problem. Is there a way to allow automatic updates without the need for weak permissions? What are the strongest permissions that can be used while still allowing automatic updates, and is that strong enough?

Celso Bessa
  • 180
  • 4
  • 9
Jenny Shoars
  • 994
  • 3
  • 16
  • 40

1 Answers1

6

The Hardening Wordpress guide describes on what's a secure setup and recommends automatic updates, but conveniently omits that the former doesn't work with them.

To my knowledge, every admin just has a very unpleasant choice to make:

  1. Keep the hardened permissions, requiring keeping on top of every single minor update and changing permissions back and forth to execute it
  2. Loosen permissions in a non-documented way and risk the associated increased insecurities

As somebody who primarily deals with automation, personally I just can't get behind the manual approach. It seems like less of a risk, but that's only if you never happen to let an update go unattended for a week or two. Then arguably the risk is higher due to the unpatched vulnerabilities than it would have been for the looser permissions.

Here's the extract that I use to switch to "insecure" mode for the few seconds it takes to update (and that I'll be using until something better comes along or my patience with this manual approach ends):

sudo chown -R <wordpress_user> <wp_rootdir>; read; sudo chown -R <myuser> <wp_rootdir>

It changes the owner of everything to the process that runs WordPress and uses the "read" command just to hold up until you press any button to then restore back to the original owner.

TL;DL: No, there is only the choice of two extremities.

insideClaw
  • 323
  • 1
  • 8
  • I think this is the solution to the problem I'm having. How do I know what the wordpress user is? There is, as far as I can tell, only one user on my server (the one I log in with). I'm assuming this is . – tobogranyte Oct 10 '19 at 13:46
  • @tobogranyte You list all the processes with `ps -ef` and look for the user (first column) that's running the WordPress process(es). I think those would usually have php in the name. – insideClaw Oct 14 '19 at 16:04
  • When I do that, the first column is a number, not a userid. – tobogranyte Oct 15 '19 at 17:36
  • Weird, maybe different version of Linux. Look at the very top of the listing to see the header names and know which column means what. You're looking for the one titled UID. – insideClaw Oct 16 '19 at 18:21
  • This seems to be a better solution than others which need changing files and directory permissions. – Akash Jul 18 '21 at 05:40