SELinux may cause mysterious permission problems
Security Enhanced Linux (SELinux) is a relatively new, powerful mechanism for fine-grained access control on Linux systems. Properly configured and maintained, it offers much better protection from misbehaving programs and exploitable security weaknesses of server application stacks than conventional Unix systems can provide. Many distributions now come with SELinux support enabled by default, or at least make it available for installation. SELinux is installed/available on Red Hat, Fedora, Debian, Gentoo, SuSE, Slackware, and Ubuntu, among others.
If you (or your ISP) are running Drupal under an operating system which has SELinux installed and enabled, you may find that certain operations fail mysteriously. Symptoms include, for example, files not being written or read though the webserver has permissions; communications operations such as sending mail or attempting XMLRPC operations failing, although firewall permissions are OK, etc.
You can confirm that SELinux is causing the problem by turning SELinux off temporarily (run the command setenforce 0 as root) and try the operation. If it succeeds, likely SELinux is the culprit. (I'm assuming that this is a development setup, not a production machine - SELinux is designed to protect your system, so turning it off on a production machine is not to be done lightly). You can get more information about exactly why SELinux is shutting you down by looking in the log files that it generates, for example, in /var/log/audit/audit.log on FC4. Look for 'avc' (access vector cache) messages.
Once you have tracked down exactly what aspect of SELinux policy is causing your operation to fail, you can modify the SELinux configuration to fix the problem. This may be as easy as turning on a boolean configuration setting in a configuration file, or as complicated as writing a new snippet of SELinux policy.
Using the avc messages, the supplied SELinux administration tools and a little bit of help from Google, the SELinux FAQs/tutorials on the web, and folks on the various the SELinux mailing lists, you should be able to find your way around configuring additional policy to get Drupal to do what you need.
I highly encourage you to bite the bullet and run with SELinux enabled, though it does involve a rather steep learning curve.
SELinux problems on FC4
I think the main reason people will be having SELinux problems on Fedora is due to the installation instructions for Drupal. These suggest the use of
mvto move the drupal source files into the web route.mvby default preserves the context associated with the file so that, if the drupal source archive was unpacked in a user's home directory, they will have the contextuser_home_t. The default SELinux settings on FC4 restrict httpd from reading files in users home directories (ie with a context ofuser_home_t).To check is this is your problem, instead of turning off SELinux as suggested above, you might try narrowing down the problem first by seeing if you can access the Drupal installation directory via your web browser after turning off the restriction on user's home directories. You can do this by running
setsebool httpd_enable_homedirs true. If you can access Drupal after runing this, then you need to reset the contexts on the moved files. You should undo the change you just made by runningsetsebool httpd_enable_homedirs false. (By the way setsebool is in/usr/sbinif you get a no such file or directory error when trying to use it -/usr/sbinmay not be in your path.)If you use
mvand are getting 403 Forbidden errors when following the installation instructions, check the SELinux context for your Drupal website. Eg. if your files are in/var/www/html/myDrupal, you can check the contexts usingls -laZ /var/www/html/myDrupal. If these files have theuser_home_tcontext, then you can fix this by runningchcon -R -t httpd_sys_content_t /var/www/html/myDrupal. Change/var/www/html/myDrupalto match where your installation is located.A global solution might be to suggest using
cpinstead ofmv, because ascpcreates a new file in the web root, the new files inherit the context of the directory - which will be the desiredhttpd_sys_content_t.Drupal on Fedora 7, FC7
Struggled with drupal installation. It's available as an rpm installable by Fedora. By default goes to /usr/share/drupal and /usr/share/docs/drupal-5.2
copied to /var/www/html, as root.
Eventual solution, for installation.
chmod 666 /var/www/html/sites/default/settings.php
then chmod 644 afterwards.
I did this after turning selinux off as above, then back on.
Still unsure if
$chcon -R -t httpd_sys_content_t /var/www/html/tdrupal
is necessary, or even
chcon -R -t httpd_sys_content_t /var/www/html/tdrupal
Further selinux problems arise when adding users. If an email is requested to be sent to them, selinux logs the error,
SELinux is preventing the sh from using potentially mislabeled files /usr/sbin/sendmail.sendmail (sendmail_exec_t).Detailed DescriptionSELinux has denied the sh access to potentially mislabeled files /usr/sbin/sendmail.sendmail.
This means that SELinux will not allow http to use these files. Many third party apps install html files in directories that SELinux policy can not predict. These directories have to be labeled with a file context which httpd can accesss.
Allowing Access
If you want to change the file context of /usr/sbin/sendmail.sendmail so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t /usr/sbin/sendmail.sendmail. You can look at the httpd_selinux man page for additional information.
You have been warned!
Final straw (for me).
SummarySELinux is preventing /usr/libexec/mysqld (mysqld_t) "search" to tmp (httpd_sys_script_rw_t).Detailed DescriptionSELinux denied access requested by /usr/libexec/mysqld. It is not expected that this access is required by /usr/libexec/mysqld and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access.Allowing AccessSometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for tmp, restorecon -v tmp If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package.
I.e. Drupal can't write to /tmp which it seems to need to do.
There's no list of read/write needs for drupal and I don't know enough of selinux to figure it all out.
As far as I can see, Drupal and SElinux are just a bit incompatible.
HTH others
DaveP
http://www.dpawson.co.uk
SELinux again
Same problem after switching to Postfix... I think Drupal needs to be fixed to work with SELinux
Summary
SELinux is preventing the sh from using potentially mislabeled files /usr/sbin/sendmail.postfix (sendmail_exec_t)
Detailed Description
SELinux has denied the sh access to potentially mislabeled files /usr/sbin/sendmail.postfix. This means that SELinux will not allow http to use these files. Many third party apps install html files in directories that SELinux policy can not predict. These directories have to be labeled with a file context which httpd can accesss.
Allowing Access
If you want to change the file context of /usr/sbin/sendmail.postfix so that the httpd daemon can access it, you need to execute it using chcon -t httpd_sys_content_t /usr/sbin/sendmail.postfix. You can look at the httpd_selinux man page for additional information.
**FIXED**
I found the fix!
For some reason there's a rogue boolean for httpd in the Other section called "httpd_can_sendmail".
Simply turn this on and you are all good!
This should surely be listed under HTTPD Service, maybe in F8 I guess.
Enjoy :)