Last updated May 1, 2010. Created on February 20, 2006.
Edited by frank0987, bryan kennedy, DyanneNova, add1sun. Log in to edit this page.

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.

Fedora Core 4 Users

Some people may be having SELinux problems on Fedora due to the installation instructions for Drupal. These suggest the use of mv to move the Drupal source files into the web root. mv by 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 context user_home_t. The default SELinux settings on FC4 restrict httpd from reading files in users home directories (ie with a context of user_home_t).

To check if 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 running setsebool httpd_enable_homedirs false. (setsebool is in /usr/sbin if you get a no such file or directory error when trying to use it - /usr/sbin may not be in your path.)

If you use mv and 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 using ls -laZ /var/www/html/myDrupal. If these files have the user_home_t context, then you can fix this by running chcon -R -t httpd_sys_content_t /var/www/html/myDrupal. Change /var/www/html/myDrupal to match where your installation is located.

A global solution might be to suggest using cp instead of mv, because cp creates a new file in the web root, the new files inherit the context of the directory - which will be the desired httpd_sys_content_t.

Fedora 7 Users

For some reason there's a rogue boolean for httpd in the Other section called "httpd_can_sendmail". This should surely be listed under HTTPD Service. Simply turn this on and you are all good!

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.