1

I installed wordpress 3.5 to CentOS 6.3 using command:

yum install wordpress

and started httpd. Now I can see the following error in apache log:

PHP Fatal error: require_once(): Failed opening required '/usr/share/wordpress/wp-includes/class-simplepie.php' (include_path='.:/usr/share/pear:/usr/share/php') in /usr/share/wordpress/wp-includes/class-feed.php on line 4, referer: http://www.mycompany.com/wp-admin/

I guess that that's because of SELinux:

ls -Z /usr/share/wordpress/wp-includes/class-simplepie.php 
lrwxrwxrwx. root root system_u:object_r:usr_t:s0 class-simplepie.php -> /usr/share/php/php-simplepie

ls -Z /usr/share/php/php-simplepie
-rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 autoloader.php
drwxr-xr-x. root root unconfined_u:object_r:user_home_t:s0 SimplePie
-rw-r--r--. root root unconfined_u:object_r:user_home_t:s0 SimplePie.php

I wonder if there is a way to let it work without disabling SELinux?

4 Answers 4

2

It looks like your files have the wrong SELinux security contexts. When I install the php-simplepie package (it appears to come from EPEL) and inspect those files, they all have the usr_t type, rather than user_home_t.

Try fixing the security labels:

restorecon -r -v /usr/share/php/php-simplepie
2
  • Your correct - I did not notice that he installed wordpress with yum. If it is from EPEL it should have the right context and they'll onlyneed to be applied. If not from EPEL then maybe he will have to apply the context I suggest, which is the context from /var/www/html.
    – Jason Tan
    Feb 11, 2013 at 15:56
  • Right you are, I install php-simplepie-1.3.1-3.el6 from EPEL, however it has user_home_t even after reinstall.....
    – Antonio
    Feb 11, 2013 at 19:53
2

If you want to verify it is SElinux turn SE linux off with setenforce 0 or check the audit.log. I think it is in /var/log/audit/audit/log but I'm not 100% sure. Once you know for sure it is SELinu you can turn SElinux back on.

If it is SElinux then the thing to do is use semanage set the selinux policy so that all of the dirs where your PHP content is to httpd_sys_rw_content_t

semanage fcontext -a -t httpd_sys_rw_content_t  </path/to/php/dir>

Then apply that policy using restorecon to the dir(s) and their children files/dirs:

restorecon -R </path/to/php/dir>

If semanage/restorecon are not installed install the policycoreutils-python package.

BTW if you want to view the default file contexts in the policy you can do that with:

semanage fcontext -l

However it may not be SELinux. I believe that out of the box apache on most redhat distros won't follow symlinks (although I thoiugh you got an error that said something about not follwoing symlinks when that was the case), so you may need to add:

Options FollowSymLinks

To the apache config and restart apache.

Of course it might be both selinux and not following symlinks.

1

Here is a little shell script I created for our developers. This way each time they roll out WordPress they don't have to remember all what to do. Your file structure is almost certainly somewhat different so will need to modify a bit. Please feel free to suggest improvements. SELinux isn't my specialization, but I'm learning it.

#!/bin/sh
# License: Public Domain
# satisfies SELinux context requirements for a WordPress site
# To operate properly on CentOS, etc.

#Figure out what directory to apply this to and strip any trailing /
if [ -d $1 ]; then
 site=${1%/}
else
 site=`pwd`
fi 

#Check to make sure the setting of $site is sane and fail if not
if [ ! -d $site/httpdocs/wp-content ]; then
  echo "ERROR: This does not appear to be an appropriate directory." 
  echo ${site}
  echo "Please specify directory for the site like /var/www/html/myssite as the only argument"
  exit 1
fi

#For visual appeal mostly
content=$site/httpdocs/wp-content

#Setup the contexts 
chcon -R -v -t public_content_rw_t $content/plugins/ $content/themes/ $content/uploads/ $site/logs/
semanage fcontext -a -t httpd_sys_rw_content_t $site/httpdocs/
semanage fcontext -a -t httpd_sys_rw_content_t $site/httpsdocs/
semanage fcontext -a -t httpd_sys_rw_content_t $site/logs/

#Apply the contexts 
restorecon -R $site/logs/
restorecon -R $site/httpdocs/
restorecon -R $site/httpsdocs/
1
  • 1
    TY for the script. The label should be really public_content_rw_t? Wouldn't httpd_sys_rw_content_t a better ideia? Sep 6, 2018 at 16:40
0

I found that this issue is a bug in EPEL:

  1. https://bugzilla.redhat.com/show_bug.cgi?id=722591
  2. https://bugzilla.redhat.com/show_bug.cgi?id=695698

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .