Bug 472642
| Summary: | SELinux denies access to /etc/drupal/default/files/ | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Christoph Wickert <christoph.wickert> |
| Component: | drupal | Assignee: | Gwyn Ciesla <gwync> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | gwync |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 6.10-1.fc9 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-03-09 22:58:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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? 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? 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. (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? (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 (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. (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? (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? (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. 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? Ping? 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. 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. 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. 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 If you do the moves manually, does it work? I may just abandon the %pre script. (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. Ok, I'll push a build gradually through rawhide, 10-test, 10, 9-test, and finally to 9. Built in rawhide. Update pushed to 10-testing. 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 drupal-6.10-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/drupal-6.10-1.fc10 drupal-6.10-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/drupal-6.10-1.fc9 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 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 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. 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. |
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.