20130417 wordpress permissions and paths - plembo/onemoretech GitHub Wiki

title: WordPress permissions and paths link: https://onemoretech.wordpress.com/2013/04/17/wordpress-permissions-and-paths/ author: phil2nc description: post_id: 4659 created: 2013/04/17 01:02:18 created_gmt: 2013/04/17 05:02:18 comment_status: closed post_name: wordpress-permissions-and-paths status: publish post_type: post

WordPress permissions and paths

In production I usually have WordPress permissioned to only give the web server user the absolute minimum rights required to run a site. But that has to change when it comes time for an upgrade. The WordPress Codex is very clear, when performing an automatic update, the web server user has to be owner of all the files and folders in the installation. That includes the installation root. This means that if you're on RHEL 6 and your installation directory is /var/www/html/blogs, then everything from "blogs" on down has to be "chown -R apache blogs" (in my installations I usually set a non-administrative user and group like "staff" to own everything except wp-content, which I set to "chown apache:staff"). It is that "staff" user that I usually have perform any ftp routines called for during the process. Once the upgrade is done I reset permissions like this:

chown -R staff:staff /var/www/html/blogs
chmod -R g+w /var/www/html/blogs
chown -R apache:staff /var/www/html/blogs/wp-content
chown apache:staff /var/www/html/blogs/wp-config.php
chmod u-w /var/www/html/blogs/wp-config.php
chmod o-rwx /var/www/html/blogs/wp-config

This prevents the web server from being able to write to anything but what's under wp-content. Another issue I've had in the past concerns WordPress complaining it can't find the path it has to write to during updates. This also turns out to usually be a permissions issue, solved by temporarily setting apache as the owner of everything from the install root down. Note that when using WP Super Cache and other plugins you may have to loosen up security in order to accomodate its need to write to different places on the file system. In some cases WordPress really is confused about where it lives, usually in subdomain installations (e.g. "blogs.example.com"). In those situations you could add something like this to your wp-config.php file:

define('FTP_BASE', '/var/www/html/blogs/');
define('FTP_CONTENT_DIR', '/var/www/html/blogs/wp-content/');
define('FTP_PLUGIN_DIR', '/var/www/html/blogs/wp-content/plugns/');