Bug 472642 - SELinux denies access to /etc/drupal/default/files/
SELinux denies access to /etc/drupal/default/files/
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: drupal (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gwyn Ciesla
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-22 07:58 EST by Christoph Wickert
Modified: 2009-03-09 19:06 EDT (History)
1 user (show)

See Also:
Fixed In Version: 6.10-1.fc9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-09 18:58:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christoph Wickert 2008-11-22 07:58:29 EST
Description of problem:
SELinux is deniying httpd to access /etc/drupal/default/files/, which causes drupal not to work

Version-Release number of selected component (if applicable):
selinux-policy-3.3.1-107.fc9
drupal-6.6-1.fc9.noarch

How reproducible:
always

Steps to Reproduce:
1. yum install drupal
2. point your webbrowser to localhost/drupal
  
Actual results:
Drupal won't work, sealert warning instead (sorry I cannot give you the error in English, but sealert does not honor LANG=C):

Zusammenfassung:

SELinux hindert httpd daran, evtl. falsch gekennzeichnete Dateien ./files
(etc_t) zu verwenden.

Detaillierte Beschreibung:

[SELinux ist im permissive Modus. Der Betrieb würde verweigert werden, wurde
aber durch den permissive Modus erlaubt.]

SELinux verweigerte httpd den Zugriff auf potentiell falsch gekennzeichnete
Dateien (./files). Dies bedeutet, dass SELinux httpd die Verwendung dieser
Dateien untersagt. Viele Dritt-Anwendungen installieren HTML-Dateien in
Verzeichnissen, die die SELinux-Richtlinie nicht vorhersehen kann. Diese
Verzeichnisse müssen mit einem Dateikontext gekennzeichnet werden, auf den
httpd zugreifen kann.

Zugriff erlauben:

Falls Sie den Dateikontext von ./files ändern möchten, so dass der httpd-
Daemon Zugriff hat, müssen Sie chcon -t httpd_sys_content_t../files verwenden.
Sie finden zusätzliche Informationen auf der httpd_selinux-Handbuchseite.

Zusätzliche Informationen:

Quellkontext                  system_u:system_r:httpd_t:s0
Zielkontext                   unconfined_u:object_r:etc_t:s0
Zielobjekte                   ./files [ dir ]
Quelle                        httpd
Quellen-Pfad                  /usr/sbin/httpd
Port                          <Unbekannt>
Host                          wicktop.localdomain
Quellen-RPM-Pakete            httpd-2.2.9-1.fc9
Ziel-RPM-Pakete               
RPM-Richtlinie                selinux-policy-3.3.1-107.fc9
SELinux aktiviert             True
Richtlinienversion            targeted
MLS aktiviert                 True
Enforcing-Modus               Permissive
Plugin-Name                   httpd_bad_labels
Hostname                      wicktop.localdomain
Plattform                     Linux wicktop.localdomain 2.6.27.5-41.fc9.i686 #1
                              SMP Thu Nov 13 20:52:14 EST 2008 i686 i686
Anzahl der Alarme             8
Zuerst gesehen                Fr 07 Nov 2008 19:37:39 CET
Zuletzt gesehen               Sa 22 Nov 2008 13:22:49 CET
Lokale ID                     d8119941-7342-42b1-9f91-6b7821b64b68
Zeilennummern                 

Raw-Audit-Meldungen           

host=wicktop.localdomain type=AVC msg=audit(1227356569.60:28): avc:  denied  { write } for  pid=2622 comm="httpd" name="files" dev=dm-0 ino=85024 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=dir

host=wicktop.localdomain type=SYSCALL msg=audit(1227356569.60:28): arch=40000003 syscall=33 success=yes exit=0 a0=b9f78988 a1=2 a2=f48a78 a3=f6ae01 items=0 ppid=2574 pid=2622 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)


Expected results:
Just works (TM)

Additional info:
SELinux is complaining about the files dir inside /etc/drupal/default/.
chcon -t httpd_sys_content_rw_t /etc/drupal/default/files/ makes the drupal work. httpd_sys_content_t also makes the warning disappear, but AFAICS some files in this dirs need to be writable by httpd.
Comment 1 Daniel Walsh 2008-11-24 09:37:13 EST
Why is drupal wrigint files in /etc/drupal/default/files/?  This directory does not exist as part of drupal package in F10?  Probably does not in F9.  /etc should be read/only, why not put these files in /var/lib/drupal?
Comment 2 Gwyn Ciesla 2008-11-24 09:50:06 EST
Because the individual site configuration files are in /etc, and each site needs it's own writable files dir.  It's ugly, I know, but there is a very thin line here between config data and application data.  Would it suffice to add chcon to the package README for initial setup?
Comment 3 Christoph Wickert 2008-11-24 11:02:37 EST
So who/what /etc/drupal/default/files/ then? I did not do it.

(In reply to comment #2)
> Would it suffice to add chcon to the package README for initial setup?

Nope, because after relabeling drupal will be broken again.
Comment 4 Gwyn Ciesla 2008-11-24 11:17:03 EST
(In reply to comment #3)
> So who/what /etc/drupal/default/files/ then? I did not do it.

Missing a verb here?  "relabled", possibly?  If so, I'm not sure.  It should get the default context of the destination parent directory, IIRC.  Could have been restorecond as well.

> (In reply to comment #2)
> > Would it suffice to add chcon to the package README for initial setup?
> 
> Nope, because after relabeling drupal will be broken again.

What if we instruct also to add and entry to /etc/selinux/restorecond.conf?
Comment 5 Christoph Wickert 2008-11-24 13:04:52 EST
(In reply to comment #4)
> Missing a verb here?  "relabled", possibly?  

Yes, there was a verb missing, but it was "created". Who/what created /etc/drupal/default/files?

> If so, I'm not sure.  It should
> get the default context of the destination parent directory, IIRC.  Could have
> been restorecond as well.

Well, it _did_ have the default context, etc_t is the context of the parent directory.


> > (In reply to comment #2)
> > > Would it suffice to add chcon to the package README for initial setup?
> > 
> > Nope, because after relabeling drupal will be broken again.
> 
> What if we instruct also to add and entry to /etc/selinux/restorecond.conf?

I have to admit that I don't really like this idea, because it is far from "just works (TM)". I tend to agree with Dan that the files should be located in /var/lib/drupal, because they get edited through httpd and not manually. Nevertheless I agree that there should be some notes regarding SELinux in drupal-README.fedora
Comment 6 Gwyn Ciesla 2008-11-24 13:15:35 EST
(In reply to comment #5)
> (In reply to comment #4)
> > Missing a verb here?  "relabled", possibly?  
> 
> Yes, there was a verb missing, but it was "created". Who/what created
> /etc/drupal/default/files?

Ah.  Well, as it's not owned by the package, I assume you did.  I have several sites, and just noticed that not all my sites have a files directory.

> > If so, I'm not sure.  It should
> > get the default context of the destination parent directory, IIRC.  Could have
> > been restorecond as well.
> 
> Well, it _did_ have the default context, etc_t is the context of the parent
> directory.
>
> 
> > > (In reply to comment #2)
> > > > Would it suffice to add chcon to the package README for initial setup?
> > > 
> > > Nope, because after relabeling drupal will be broken again.
> > 
> > What if we instruct also to add and entry to /etc/selinux/restorecond.conf?
> 
> I have to admit that I don't really like this idea, because it is far from
> "just works (TM)". I tend to agree with Dan that the files should be located in
> /var/lib/drupal, because they get edited through httpd and not manually.
> Nevertheless I agree that there should be some notes regarding SELinux in
> drupal-README.fedora

Does this still stand if they're user(admin)-created?  What if /etc/drupal/default/files was symlinked to /var/lib/drupal/somethingorother/default, with instructions to create and symlink?  It would likely solve the selinux issue but be a bit of a pain.
Comment 7 Christoph Wickert 2008-11-24 15:05:03 EST
(In reply to comment #6)

> Ah.  Well, as it's not owned by the package, I assume you did.  

I definitely did not create it, at least no by hand. All files inside are owned by apache and were created 20 minutes after installing the drupal package for the first time, so I guess it has been created through the installation wizard.
For example I have a /etc/drupal/default/files/.htaccess file that reads:

  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
  Options None
  Options +FollowSymLinks

So it is clear that it has been created be httpd, and to me this is a no-go. httpd must not (be able to) write somewhere inside of /etc.

> I have several
> sites, and just noticed that not all my sites have a files directory.

This is most likely because you don't have any language packs installed. The only file in the dir (except from the .htaccess I mentioned) is called
/etc/drupal/default/files/languages/de_f0ad935ebdeed0b3994a75987635fd78.js


> Does this still stand if they're user(admin)-created?  What if
> /etc/drupal/default/files was symlinked to
> /var/lib/drupal/somethingorother/default, with instructions to create and
> symlink?  It would likely solve the selinux issue but be a bit of a pain.

Sorry, I don't understand your suggestion. I think it should be linked to somewhere in /var/lib/drupal, but what is the second symlink you are talking about?
Comment 8 Gwyn Ciesla 2008-11-24 15:19:02 EST
(In reply to comment #7)
> (In reply to comment #6)
> 
> > Ah.  Well, as it's not owned by the package, I assume you did.  
> 
> I definitely did not create it, at least no by hand. All files inside are owned
> by apache and were created 20 minutes after installing the drupal package for
> the first time, so I guess it has been created through the installation wizard.
> For example I have a /etc/drupal/default/files/.htaccess file that reads:
> 
>   SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
>   Options None
>   Options +FollowSymLinks
> 
> So it is clear that it has been created be httpd, and to me this is a no-go.
> httpd must not (be able to) write somewhere inside of /etc.

Agreed that it was created by httpd.

> > I have several
> > sites, and just noticed that not all my sites have a files directory.
> 
> This is most likely because you don't have any language packs installed. The
> only file in the dir (except from the .htaccess I mentioned) is called
> /etc/drupal/default/files/languages/de_f0ad935ebdeed0b3994a75987635fd78.js
> 
> 
> > Does this still stand if they're user(admin)-created?  What if
> > /etc/drupal/default/files was symlinked to
> > /var/lib/drupal/somethingorother/default, with instructions to create and
> > symlink?  It would likely solve the selinux issue but be a bit of a pain.
> 
> Sorry, I don't understand your suggestion. I think it should be linked to
> somewhere in /var/lib/drupal, but what is the second symlink you are talking
> about?
I was using it as a placeholder.  Let's say you have 3 drupal sites, one default, one for http://www.example.com and one for http://fishfingers.example.org.  You'd have in /etc:

/etc/drupal/default/
/etc/drupal/www.example.com/
/etc/drupal/fishfingers.example.org/

which would hold the configuration files for the sites.  Then, you'd have symlinks:

/etc/drupal/default/files -> /var/lib/drupal/files/default/
/etc/drupal/www.example.com/ -> /var/lib/drupal/files/www.example.com/
/etc/drupal/fishfingers.example.org/ -> /var/lib/drupal/files/fishfingers.example.com/

Cumbersome, but would it not fix the selinux issues?
Comment 9 Christoph Wickert 2008-11-24 15:40:27 EST
(In reply to comment #8)
> Then, you'd have symlinks:
> 
> /etc/drupal/default/files -> /var/lib/drupal/files/default/
> /etc/drupal/www.example.com/ -> /var/lib/drupal/files/www.example.com/
> /etc/drupal/fishfingers.example.org/ ->
> /var/lib/drupal/files/fishfingers.example.com/
> 
> Cumbersome, but would it not fix the selinux issues?

I don't think it's cumbersome, to me it looks logical and I assume it will fix the selinux trouble.
Comment 10 Gwyn Ciesla 2008-11-24 15:53:02 EST
Ok, let's say I do this (which I am inclined to do, FWIW).   How do we handle the upgrade process?  %post script for this version only that runs only if it's an upgrade?  It would also have to call chcon manually.  Any pitfalls I'm not thinking of, or just include instructions in the bodhi update?
Comment 11 Gwyn Ciesla 2008-12-31 13:56:28 EST
Ping?
Comment 12 Christoph Wickert 2008-12-31 15:42:45 EST
Sorry, I lost track of this. :(

Regarding the upgrade process: It's your decision. IMHO we should use %post, because people are most likely not going to see the bodhi notes and will be left with a broken drupal instance after the update.
Comment 13 Gwyn Ciesla 2009-01-02 12:44:14 EST
Ok.  I'll try to make up my mind what I want to do.  I'm always leery about touching something the rpm doesn't own, so I'd really rather do just /etc/drupal/default/files, and have the user to the rest themselves, maybe including a script to do them in bulk if they like.
Comment 14 Gwyn Ciesla 2009-01-02 16:05:16 EST
Please test drupal-6.8-1.fc11 in rawhide.  It should move your /etc/drupal/default/files and symlink in, and it includes very rough script to allow you to do the rest.

Don't forget to log in as user 1 first to do the DB upgrade.
Comment 15 Christoph Wickert 2009-01-11 12:36:46 EST
Sorry it took so long, but I wanted to test this properly. On the other hand I did not want to test it in my productive enviromnent...

Your fix does not work, because /etc/drupal/default/files is marked %config/noreplace) :(

$ ls -l /etc/drupal/default/
insgesamt 28
-rw-r--r-- 1 root root 8917 13. Aug 08:52 default.settings.php
drwxrwxrwx 4 root root 4096  7. Nov 19:53 files
lrwxrwxrwx 1 root root   37 11. Jan 14:51 files.rpmnew -> ../../../var/lib/drupal/files/default
-rw-r--r-- 1 root root 8908 14. Sep 06:30 settings.php
Comment 16 Gwyn Ciesla 2009-01-15 09:28:08 EST
If you do the moves manually, does it work?  I may just abandon the %pre script.
Comment 17 Christoph Wickert 2009-02-16 19:16:11 EST
(In reply to comment #16)
> If you do the moves manually, does it work?  I may just abandon the %pre
> script.

Yes, that worked. Unfortunately I can't do any more tests because I did a fresh install of F10 in the meantime. Sorry I missed to do more debugging.
Comment 18 Gwyn Ciesla 2009-02-17 12:58:19 EST
Ok, I'll push a build gradually through rawhide, 10-test, 10, 9-test, and finally to 9.
Comment 19 Gwyn Ciesla 2009-02-17 13:47:55 EST
Built in rawhide.
Comment 20 Gwyn Ciesla 2009-02-18 10:37:51 EST
Update pushed to 10-testing.
Comment 21 Fedora Update System 2009-02-24 16:02:35 EST
drupal-6.9-2.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update drupal'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2061
Comment 22 Fedora Update System 2009-02-26 09:01:35 EST
drupal-6.10-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/drupal-6.10-1.fc10
Comment 23 Fedora Update System 2009-02-26 09:01:49 EST
drupal-6.10-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/drupal-6.10-1.fc9
Comment 24 Fedora Update System 2009-02-27 22:21:37 EST
drupal-6.10-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update drupal'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-2175
Comment 25 Fedora Update System 2009-02-27 22:27:14 EST
drupal-6.10-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update drupal'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-2182
Comment 26 Fedora Update System 2009-03-09 18:58:36 EDT
drupal-6.10-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 27 Fedora Update System 2009-03-09 19:05:54 EDT
drupal-6.10-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.