Summary: SELinux is preventing /usr/sbin/httpd from using potentially mislabeled files 425fd4320d8bc71badaab71a91b18f6b. Detailed Description: SELinux has denied the httpd access to potentially mislabeled files 425fd4320d8bc71badaab71a91b18f6b. 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_run_t, squirrelmail_spool_t, httpd_rw_content, httpd_cache_t, httpd_tmpfs_t, httpd_tmp_t, httpd_squirrelmail_t, httpd_squid_content_rw_t, httpd_apcupsd_cgi_content_rw_t, httpd_prewikka_content_rw_t, httpd_awstats_content_rw_t, httpd_w3c_validator_content_rw_t, httpd_user_content_rw_t, httpd_cobbler_content_rw_t, httpdcontent, httpd_munin_content_rw_t, httpd_bugzilla_content_rw_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_nutups_cgi_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 425fd4320d8bc71badaab71a91b18f6b so that the httpd daemon can access it, you need to execute it using semanage fcontext -a -t FILE_TYPE '425fd4320d8bc71badaab71a91b18f6b'. where FILE_TYPE is one of the following: httpd_var_run_t, squirrelmail_spool_t, httpd_rw_content, httpd_cache_t, httpd_tmpfs_t, httpd_tmp_t, httpd_squirrelmail_t, httpd_squid_content_rw_t, httpd_apcupsd_cgi_content_rw_t, httpd_prewikka_content_rw_t, httpd_awstats_content_rw_t, httpd_w3c_validator_content_rw_t, httpd_user_content_rw_t, httpd_cobbler_content_rw_t, httpdcontent, httpd_munin_content_rw_t, httpd_bugzilla_content_rw_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_nutups_cgi_content_rw_t. You can look at the httpd_selinux man page for additional information. Additional Information: Source Context system_u:system_r:httpd_t:s0 Target Context system_u:object_r:var_lib_t:s0 Target Objects 425fd4320d8bc71badaab71a91b18f6b [ dir ] Source httpd Source Path /usr/sbin/httpd Port <Unknown> Host (removed) Source RPM Packages httpd-2.2.14-1.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-114.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name httpd_bad_labels Host Name (removed) Platform Linux (removed) 2.6.32.12-115.fc12.x86_64 #1 SMP Fri Apr 30 19:46:25 UTC 2010 x86_64 x86_64 Alert Count 15 First Seen Tue 25 May 2010 19:54:02 BST Last Seen Tue 25 May 2010 19:54:02 BST Local ID a7e7479d-5302-47f2-b67a-00c8f7facf08 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1274813642.479:5908): avc: denied { create } for pid=25447 comm="httpd" name="425fd4320d8bc71badaab71a91b18f6b" scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1274813642.479:5908): arch=c000003e syscall=83 success=no exit=-13 a0=7f795ad4b488 a1=1ed a2=8 a3=7f795a3075d0 items=0 ppid=25443 pid=25447 auid=4294967295 uid=48 gid=489 euid=48 suid=48 fsuid=48 egid=489 sgid=489 fsgid=489 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null) Hash String generated from httpd_bad_labels,httpd,httpd_t,var_lib_t,dir,create audit2allow suggests: #============= httpd_t ============== allow httpd_t var_lib_t:dir create;
I installed the dokuwiki package on a Fedora 12 install (with web server option at install time) and received the above SELinux denial when I attempted to navigate to http://localhost/dokuwiki/. I received 104 identical SELinux denials in total. The dokuwiki webpage displayes numerous "Creating directory /var/lib/dokuwiki/data/cache/d failed" errors.
Applying 'httpd_sys_content_t:s0' to all files in '/var/lib/dokuwiki(/.*)?' seems to fix this. I'm not sure how its done for other packages (I'm new to Fedora but was a Debian user for many years) but I think this either needs documenting or adding to the rpm spec file or the default SELinux policy.
Does this entire directory need to be written to by dokuwiki? Fixed in selinux-policy-3.7.19-22.fc13.noarch Miroslav can you add /var/lib/dokuwiki(/.*)? gen_context(system_u:object_r:httpd_sys_rw_content_rw_t,s0) to F12.
(In reply to comment #3) > Does this entire directory need to be written to by dokuwiki? > I believe it does. The Dokuwiki package is setup such that the main Dokuwiki files are in /usr/share.dokuwiki with a symlink from /usr/share/dokuwiki/conf -> /etc/dokuwiki and Dokukwiki iteself configured to use /var/lib/dokuwiki/data for its data (where it stores the wiki content as plain text files and its cache). I believe only files it writes to are store in the /var/lib/dokuwiki directory as all the static and config bits are in /usr/share/dokuwiki and /etc/dokuwiki respectively.
Ok Miroslav go for it.
I've had a few more SELinux hits with this package today. It also needs write access to /etc/dokuwiki(/.*)? and read to /usr/share/dokuwiki(/.*)? If you look at the drupal directory entries in the default SELinux policy exactly the same needs to be applied to the dokuwiki directories for it to work at all (i.e. a stright s/drupal/dokuwiki/ on the drupal policy would render a policy which gets basic functionality working in dokuwiki). I have not been able to get the in-built plugin management web interface to be able to download and install plugins - strangely I'm not getting any SELinux denied messages regarding this but it does works perfectly if I throw SELinux into permissive rather than enforcing mode (but still nothing appears in the audit log) :S
If you execute semodule -DB It will turn off all dontaudit rules. Then you should see what is blocking. semodule -B Turns them back on.
(In reply to comment #3) > Does this entire directory need to be written to by dokuwiki? > > Fixed in selinux-policy-3.7.19-22.fc13.noarch > > Miroslav can you add > > /var/lib/dokuwiki(/.*)? > gen_context(system_u:object_r:httpd_sys_rw_content_rw_t,s0) > > to F12. Is it really fixed in F13? I installed dokuwiki rpm in F13 system and file structure in /var/lib/dokuwiki/data still has system_u:object_r:var_lib_t:s0 context. [root@atom ~]# ll -Z /var/lib/dokuwiki/data/ drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 attic drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 cache drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 index drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 locks drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 media drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 meta drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 pages drwxr-xr-x. apache apache system_u:object_r:var_lib_t:s0 tmp
Fixed in selinux-policy-3.7.19-36.fc13
I tried it (selinux-policy and selinux-policy-targeted version 3.7.19-36.fc13) from koji, but during installation it throwed this error: /etc/selinux/targeted/contexts/files/file_contexts: Multiple different specifications for /usr/libexec/telepathy-sofiasip (system_u:object_r:telepathysofiasip_exec_t:s0 and system_u:object_r:telepathy_sofiasip_exec_t:s0). /etc/selinux/targeted/contexts/files/file_contexts: Invalid argument libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! And directories in /var/lib/dokuwiki/data still have system_u:object_r:var_lib_t:s0 context and are not writeable.
I am fixing this issue. You can run # semodule -r telepathysofiasip and then try to install selinux-policy-targeted again. Will fix. Updated selinux-policy packages will be available today.
selinux-policy-3.7.19-37.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-37.fc13
selinux-policy-3.7.19-37.fc13 has been pushed to the Fedora 13 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/selinux-policy-3.7.19-37.fc13
Now it works fine ;-) Thank you very much!
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
For me this bug is already fixed in F13 (as i wrote on 2010-07-15).
Thanks for your help.