WordPress file permissions and upgrades with wpfix.py

(Post updated 2015-05-07 with the results of some helpful feedback from mbrowne. Comments, GitHub issues and pull requests are always welcome!)

I maintain a Github repository of small useful scripts (at least to me) and occasionally get comments or email about them. I received an email yesterday asking about WordPress file permissions when applied with wpfix.py, which is a simple Python wrapper around a few common filesystem operations. I’d initially written about it a few years ago as a utility to allow sites to auto-update.

Since wpfix.py was written, it appears that there have been some changes in the way that WordPress performs upgrades. I’ll excerpt the issue from the original email:

I have recently ran your script on our wordpress website to fix permission issue.

But we are getting below error while we try to upgrade wordpress from admin panel.

 

“This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php”

 

When i look the permission I could see update-core.php file have only read permission for webserver user “www-data”. Is your script designed to set 644 for files in this folder ?

-rw-r--r-- 1 username www-data  47326 Aug  1 06:09 update-core.php

 

I took it upon myself to read some of the WordPress code that performs core updates, as well as some of the documentation. To answer the original question, wpfix.py does set 644 permissions on all WordPress files in the directory tree, then goes through the wp-content directory and adds group write permissions only where necessary.

The auto-update documentation at http://codex.wordpress.org/Hardening_WordPress states:

When you tell WordPress to perform an automatic update, all file operations are performed as the user that owns the files, not as the web server’s user. All files are set to 0644 and all directories are set to 0755, and writable by only the user and readable by everyone else, including the web server.

Unfortunately this doesn’t seem to match with the behavior in the code – when a direct FS_METHOD is used for manipulating files rather than through FTP or SSH, operations get performed as the web server user (www-data). Therefore, the 644 permissions on wp-admin are too restrictive to allow core upgrades.

There are a few solutions to this problem:

• If you do not accept the risks of having the webserver (www-data) user having write access to your WordPress contents, use the wp-cli (http://wp-cli.org/) core update command running as the user that owns the WordPress files. This is my preferred method and it can be scripted to batch update sites.
• If you completely control the webserver and can be assured that nobody will upload a potentially malicious plugin or execute code that traverses the filesystem, set the permissions to 664 for all files (not directories) under wp-admin and wp-includes directories and have the group set to www-data:


  • find $WORDPRESS_DIR/wp-admin -type f -exec chmod 664 {} \;
    find $WORDPRESS_DIR/wp-includes -type f -exec chmod 664 {} \;
    chgrp -R www-data $WORDPRESS_DIR/wp-{admin,includes}

  • I would not recommend this in a shared hosting environment. When you upgrade, the more permissive group write flag will be preserved on these files (see the WP_Filesystem function in wp-admin/includes/file.php for details on how FS_CHMOD_DIR and FS_CHMOD_FILE are set.)
• If you have FTP or SSH access to the server, and want to upgrade using this technique, remove the define('FS_METHOD', 'direct'); line from wp-config.php. This ensures that file delete, write and move operations are performed as the FTP/SSH user.

I will be adding parameters to wpfix.py shortly to address the last two points, and allow users to either set more permissive permissions on wp-admin/wp-includes directories or remove the FS_METHOD define.