Updated (Jan 5, 2012): chcon changes the SELinux security on a file, but a restorecon would wipe that out, you need to actually run semanage to change the policy, then run restorecon to make it “permanent”. Thanks to firstname.lastname@example.org for pointing this out to me.
So I recently started upgrading all the CloudSecurityAlliance web servers from F14 (with SELinux enabled) to F16 (with SELinux enabled). But I ran into a nasty little problem, WP Super Cache was broken. The error message that came up was:
Error: Your cache directory (/var/www/html/wp-content/cache/) or /var/www/html/wp-content need to be writable for this plugin to work. Double-check it. Cannot continue... fix previous problems and retry.
Well shoot. The file permissions were correct, apache had write permissions and so on to the directory. But it was unable to write… Ah.. must be SELinux. The quickest way to test this is to simply disable SELinux for a second:
and reload the WP Super Cache control page. Ah it works. So we know it’s an SELinux problem. The good news is that this is easy to fix, simply set the label on the directories and files you want the httpd process to be able to write to (and don’t forget to re-enable SELinux after you disabled it in the previous step):
You can use chcon to change the content on the directories:
chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/cache/ chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/plugins/ chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/themes chcon -R -t httpd_sys_rw_content_t /var/www/html/wp-content/uploads/ chcon -t httpd_sys_rw_content_t /var/www/html/wp-content/wp-cache-config.php
For a more permanent change however use semanage to change the targeted policy:
semanage -S targeted -i - << _EOF fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/cache(/.*)? fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/uploads(/.*)? fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/plugins(/.*)? fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/themes(/.*)? fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/wp-cache-config.php fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/themes(/.*)? fcontext -a -t httpd_sys_rw_content_t /var/www/html/wp-content/blogs.dir(/.*)? _EOF
restorecon -R -v /var/www/html
Also you may want to add “/var/www/html/wp-content/blogs.dir(/.*)?” so that WordPress multi-site uploads work properly.
Be mindful of selinux policy updates, they shouldn’t overwrite the changes you made but you may want to in order to get the latest greatest policies. Also you probably won’t have semanage installed:
yum install policycoreutils-python
Ok that was easy. But how do we find out what label needs to be applied? Well the ls command can give us a hint:
ls -dZ /var/www/html drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html
So we’re dealing with httpd (obviously, but for other servers and services it may not be as simple so I’m doing this step by step). We can check for httpd related contexts using grep:
grep httpd /etc/selinux/targeted/contexts/files/file_contexts
Which will return a huge list of stuff. If you examine the output however you will notice lines like:
/var/lib/drupal.* system_u:object_r:httpd_sys_rw_content_t:s0 /var/cache/mediawiki(/.*)? system_u:object_r:httpd_cache_t:s0
So it would appear we have two main choices: httpd_sys_rw_content_t and httpd_cache_t. There are a number of other related labels as well: httpd_mediawiki_rw_content_t, httpd_git_rw_content_t, httpd_bugzilla_rw_content_t, httpd_mojomojo_rw_content_t and httpd_dspam_content_rw_t to name a few. Any of these will work, but I chose httpd_sys_rw_content_t as it;s rpetty obvious as to what it is for at first glance.
For more details on Red Hat Enterprise Linux (this also applies to Fedora) with SELinux and confined services check the Red Hat documentation: