Bug 533694
| Summary: | SELinux is preventing /usr/sbin/httpd from using potentially mislabeled files settings.php. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Maarten <m.menheere> |
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 12 | CC: | dwalsh, gwync, mgrepl |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | setroubleshoot_trace_hash:544bfce742a79749a89518c3aec34f54d92ef766539975ebe4ab2e9382e382c8 | ||
| Fixed In Version: | 3.6.32-49.fc12 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-12-01 16:40:04 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: | |||
Where is settings.php under /etc? You need to change the context as described in the setroubleshoot. If this is a standard path then please reopen the bugzilla. man httpd_selinux Will give you additional info. Yes, I found out about chcon. Easier than I thought it was. But installing drupal is still not very userfriendly. There is a fedora specific install readme file. The does not explicitly mention the se policy change you have to do and where to place the settings.php for a local setup. The setroubleshoot window was very helpfull however. To get it working I had to do this. copy settings template to var drupal folder cp /etc/drupal/default/default.settings.php /var/lib/drupal/files/default/settings.php set selinux type chcon -t httpd_var_lib_t /var/lib/drupal/files/default/settings.php create a symlink from etc folder to var folder ln -s /var/lib/drupal/files/default/settings.php /etc/drupal/default/settings.php In F12 you would not need to do the chcon, the default label for this directory is httpd_sys_content_rw_t which would allow the access. Just copying the file and setting up the symbolic link would solve the problem drupal should make this the default. reassigning to the drupal package. (In reply to comment #3) > In F12 you would not need to do the chcon, the default label for this directory > is httpd_sys_content_rw_t which would allow the access. Just copying the file > and setting up the symbolic link would solve the problem > > drupal should make this the default. > > reassigning to the drupal package. The settings.php file is a config file and belongs in /etc. Would doing the chcon in %post be sufficient? A config file that changes should not be in /etc. /etc should be treated as R/O. If settings.php is only written by an admin then leave it in /etc. If it needs to be modified by the web app then we need ti somewhere else. If you want the file in /etc then I would prefer to have a parent directory that we could label in such a way that httpd can write to it, and not worry about the file loosing its label. It only needs to be writable at install time, and it is in a parent directory, /etc/drupal, within whatever site it's part of, which is 'default' for a single-site installation. But is it installed at the web site? This is only going to happen once? If we label it as httpd_t can write to it, then a bug in drupal or any other app would allow overwriting the file. We can label it httpd_sys_content_rw_t and as long as it is in the payload of the rpm it will get labeled correctly. If you are creating it in the post install then you would need to run restorecon on it. Doing chcon in the post install is not a good idea. So essentially, I need to include restorecon line in the fedora-specific README file installation instructions? No the admin should not be required to do anything. Fedora should make sure this is labeled correctly. I believe the file should be in a different location, but if Fedora Maintainer wants it in the /etc directory then he needs to ensure it is labeled correctly in the spec file either my including the path in the payload or by running restorecon after the file is created in the post install script. restorecon in post I can do. What do you mean by including the path in the payload. I'm willing to do it, just not sure how. /etc/drupal/default/default\.settings\.php -- gen_context(system_u:object_r:httpd_sys_content_rw_t,s0) I will add this mapping Fixed in selinux-policy-3.6.32-47.fc12.noarch It is in the payload, so the file will be labeled as rw by apache. Shouldn't it be /etc/drupal/default/settings\.php instead So then I do the restorecon in post, and we're fine. WRT to the settings.php for other sites, I'll have to add chcon instructions to the README, unless you can change /etc/drupal/default/settings\.php to /etc/drupal/*/settings\.php or /etc/drupal/\*/settings\.php, as applicable. What files are in /etc/drupal, that the web site should not be allowed to edit? rpm -ql drupal | grep settings.php /etc/drupal(/.*)? gen_context(system_u:object_r:httpd_sys_content_rw_t,s0) Will set the directory and all subdirs as having this context. Then if the admin creates any file/dir under /etc/drupal, it will automatically be able to be r/w from apache. Well, really nothing. It's pretty much settings.php and the symlink to the files directory, which should all be modifiable from the site, so yeah, /etc/drupal should be fine. /etc/drupal(/.*)? gen_context(system_u:object_r:httpd_sys_content_rw_t,s0) Fixed in selinux-policy-3.6.32-47.fc12.noarch So now I just restorecon (possibly /etc/drupal) in post and that's it? Nope you do not need to do anything. rpm will handle it for you. So I can close this? I usually leave it open until the packages shows up in updates. Sounds good, thanks. selinux-policy-3.6.32-49.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-49.fc12 selinux-policy-3.6.32-49.fc12 has been pushed to the Fedora 12 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 selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12131 selinux-policy-3.6.32-49.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report. |
Summary: SELinux is preventing /usr/sbin/httpd from using potentially mislabeled files settings.php. Detailed Description: SELinux has denied the httpd access to potentially mislabeled files settings.php. This means that SELinux will not allow httpd to use these files. If httpd should be allowed this access to these files you should change the file context to one of the following types, httpd_var_lib_t, httpd_var_run_t, squirrelmail_spool_t, httpd_lock_t, httpd_rw_content, httpd_cache_t, httpd_tmpfs_t, httpd_tmp_t, httpd_squirrelmail_t, httpd_nagios_content_rw_t, httpd_sys_content_rw_t, httpd_sys_content_rw_t, httpd_cvs_content_rw_t, httpd_git_content_rw_t, httpd_squid_content_rw_t, httpd_apcupsd_cgi_content_rw_t, httpd_awstats_content_rw_t, httpd_prewikka_content_rw_t, httpd_w3c_validator_content_rw_t, httpd_user_content_rw_t, httpdcontent, httpd_munin_content_rw_t, root_t, httpd_bugzilla_content_rw_t. Many third party apps install html files in directories that SELinux policy cannot predict. These directories have to be labeled with a file context which httpd can access. Allowing Access: If you want to change the file context of settings.php so that the httpd daemon can access it, you need to execute it using semanage fcontext -a -t FILE_TYPE 'settings.php'. where FILE_TYPE is one of the following: httpd_var_lib_t, httpd_var_run_t, squirrelmail_spool_t, httpd_lock_t, httpd_rw_content, httpd_cache_t, httpd_tmpfs_t, httpd_tmp_t, httpd_squirrelmail_t, httpd_nagios_content_rw_t, httpd_sys_content_rw_t, httpd_sys_content_rw_t, httpd_cvs_content_rw_t, httpd_git_content_rw_t, httpd_squid_content_rw_t, httpd_apcupsd_cgi_content_rw_t, httpd_awstats_content_rw_t, httpd_prewikka_content_rw_t, httpd_w3c_validator_content_rw_t, httpd_user_content_rw_t, httpdcontent, httpd_munin_content_rw_t, root_t, httpd_bugzilla_content_rw_t. You can look at the httpd_selinux man page for additional information. Additional Information: Source Context unconfined_u:system_r:httpd_t:s0 Target Context unconfined_u:object_r:etc_t:s0 Target Objects settings.php [ file ] Source httpd Source Path /usr/sbin/httpd Port <Unknown> Host (removed) Source RPM Packages httpd-2.2.13-4.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-41.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name httpd_bad_labels Host Name (removed) Platform Linux (removed) 2.6.31.5-122.fc12.i686 #1 SMP Thu Nov 5 02:08:26 EST 2009 i686 i686 Alert Count 6 First Seen Sun 08 Nov 2009 04:17:43 PM CET Last Seen Sun 08 Nov 2009 04:53:12 PM CET Local ID 6257ebca-abf8-4b84-823b-8e10d8c465c7 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1257695592.985:152): avc: denied { setattr } for pid=5497 comm="httpd" name="settings.php" dev=dm-0 ino=133566 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:etc_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1257695592.985:152): arch=40000003 syscall=15 success=no exit=-13 a0=233d89c a1=1b6 a2=12fa4c8 a3=20d8528 items=0 ppid=5490 pid=5497 auid=500 uid=48 gid=490 euid=48 suid=48 fsuid=48 egid=490 sgid=490 fsgid=490 tty=(none) ses=1 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null) Hash String generated from selinux-policy-3.6.32-41.fc12,httpd_bad_labels,httpd,httpd_t,etc_t,file,setattr audit2allow suggests: #============= httpd_t ============== allow httpd_t etc_t:file setattr;