Description of problem:
There are several selinux label problems.
Specifically /var/lib/drupal and /etc/drupal both need to be labelled with a
fcontext -t httpd_sys_content_t
/etc/drupal is where the configuration files are stored and /var/lib/drupal is
where uploads, etc are stored... They are symlinks from /usr/share/drupal/sites
and /usr/share/drupal/files respectively for the case of a R/O /usr.
Version-Release number of selected component (if applicable):
drupal-5.5-1.fc8 and selinux-policy-targeted-3.0.8-72.fc8
Steps to Reproduce:
1. On drupal setup - chmod 666 /etc/drupal/default/settings.php and get an
selinux denial on installation
2. If you have a database setup - enable compressed css files - again you get a
failure and /var/lib/drupal/css is not written.
In (1) - supported database not found error.
For (2) - the screen is displayed w/o css settings and looks different...
No selinux denials
My workaround is to
/usr/sbin/semanage fcontext -a -t httpd_sys_content_t "/var/lib/drupal(/.*)?"
/usr/sbin/semanage fcontext -a -t httpd_sys_content_t "/etc/drupal(/.*)?"
and restorecon -R /etc/drupal and /var/lib/drupal.
This may be a drupal bug - but I believe this is the proper place...
(In reply to comment #0)
> Description of problem:
> There are several selinux label problems.
> Specifically /var/lib/drupal and /etc/drupal both need to be labelled with a
> fcontext -t httpd_sys_content_t
> /etc/drupal is where the configuration files are stored and /var/lib/drupal is
> where uploads, etc are stored... They are symlinks from /usr/share/drupal/sites
> and /usr/share/drupal/files respectively for the case of a R/O /usr.
With the *default* configuration, files are uploaded in
(In reply to comment #1)
> With the *default* configuration, files are uploaded in
Oops, it's :
Sorry, forget my previous comments (#1 and #2) because I use drupal-6.0-dev and
not drupal-5.5 (I repackaged Fedora src.rpm for drupal-6.0-0dev).
Any way, I play around with Drupal and I have some difficulties to get it rigth
For example, I can pointe the browser to
But settings.php contains the uri (with the password) of the database used. As
long as php is enabled, it's OK (not really sure). But if php is disabled you
can get the file (and any password it contains).
Drupal permit to upload files. By *default* uploaded files are public and
delivered by apache (not via Drupal). This also bypass any access restriction of
Drupal. If the administrator of drupal permit uploading php files (or perl ...),
these files can be executed by apache. NB : The administrator of drupal can do
this, not only the person who installed Drupal (you strictly follow
I'll check the fedora package again when it will have Drupal 6.0 and fill
bugzilla if I find some security issue.
The drupal package use php in module (by default). Not php in cgi mode.
I am not sure this bug belong to selinux-policy-targeted.
Ok I am just getting around to looking at this bugzilla.
Should allow drupal to work. I did not understand the other section. Drupal
should not be writing to /etc partition. This is considered a read only partition.
Any files that need to be written should be moved to /var/lib/drupal
Fixed in selinux-policy-3.0.8-89.fc8
(In reply to comment #5)
> /usr/share/drupal(/.*)? gen_context(system_u:object_r:httpd_sys_content_t,s0)
I don't need this one.
[admin@one ~]$ rpm -q selinux-policy
[admin@one ~]$ ll -Z /usr/share/drupal/
-rw-r--r-- root root system_u:object_r:usr_t:s0 COPYRIGHT.txt
-rw-r--r-- root root system_u:object_r:usr_t:s0 cron.php
User firstname.lastname@example.org's account has been closed
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.