Description of problem: I recently started to get warnings from setroubleshoot that the http daemon had been prevented from reading users' home directories, one warning for each user account. And it said I should set httpd_enable_homedirs if I wanted to allow this access. That had been quite expected if I intended to allow access to use the "public_html" feature in users' home directories. But I do not. I have the default "UserDir disabled" in my httpd.conf. I even tried by commenting out the LoadModule line loading mod_userdir.so, but httpd obviously still tries to do this access. Version-Release number of selected component (if applicable): httpd-2.2.13-4.fc12.x86_64 selinux-policy-3.6.32-52.fc12.noarch How reproducible: Every time Steps to Reproduce: 1.Make sure UserDir is disabled in httpd.conf 2.Start httpd Actual results: SELinux messages like these: time->Mon Dec 7 14:00:20 2009 type=SYSCALL msg=audit(1260190820.405:34477): arch=c000003e syscall=4 success=no exit=-13 a0=7f70c7627c58 a1=7fff8b8b6500 a2=7fff8b8b6500 a3=1999999999999999 items=0 ppid=30398 pid=30400 auid=503 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=38 comm="httpd" exe="/usr/sbin/httpd" subj=unconfined_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1260190820.405:34477): avc: denied { search } for pid=30400 comm="httpd" name="ulrika" dev=dm-0 ino=4374872 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir Expected results: No SELinux alerts, no attempts by httpd to access home directories. Additional info: I was unsure if I should report this here or upstreams, but I decided to start here. Let me know if I should take it upstreams instead.
What entries do you have in /var/log/httpd/*access_log around that time? I'm not sure what would cause this.
These warnings come when I (re)start httpd. There were no accesses precisely at that time: host-13-103-cust.prq.se - - [07/Dec/2009:13:57:33 +0100] "GET / HTTP/1.0" 200 1826 "-" "DriftStatus.Com engine (compatible; driftstatus Crawl; http check (<a href='http://driftstatus.com/info.html'>driftstatus.com</a>)" host-13-103-cust.prq.se - - [07/Dec/2009:14:10:08 +0100] "GET / HTTP/1.0" 200 1826 "-" "DriftStatus.Com engine (compatible; driftstatus Crawl; http check (<a href='http://driftstatus.com/info.html'>driftstatus.com</a>)"
Created attachment 441869 [details] SELinux is preventing the http daemon from reading users' home directories. Same problem here for a while now. I have not altered my httpd.conf and UserDir is disabled.
Forgot to mention this is on Fedora 13 x86_64 fully updated.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. 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 '12'. 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 12'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 12 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
This is still hapenning to me in Fedora 13 as I've stated but I don't appear to have access to change the version.
> I don't appear to have access to change the version. At your service! :-) I'm planning to check it on F14, but I'll switch to F13 for now.
I'll test on 14 as soon as I can. I'm doing a preupgrade on my laptop right now since it's not critical that it be in working order unlike my desktop.
I've now upgraded to httpd-2.2.16-1.fc14, and I still get the error.
I can confirm after preupgrade from F13 to F14 this is still occurring.
I have been looking at this too. It is caused by gnome-user-share and mod_dnssd packages/modules. yum remove mod_dnssd gnome-user-share Thisfixes for me. But I guess the question is is whether this is (and if so, should it) be installed by default. On our network this automounts lots and lots of homedirs. This is also an issue in RHEL 6.
Ping... Any news about possible fixes?
I'm trying to reproduce it on F15 with httpd-2.2.17-10.fc15.1.x86_64 and selinux-policy-3.9.16-30.fc15 and it does not show any error message for me. I don't have any F14 here just now, but if it does not work for you on F15, please tell me.
I still see those AVC:s. I rebooted my server yesterday evening, and doing an ausearch now I find this, among others: time->Mon Aug 8 22:22:53 2011 type=SYSCALL msg=audit(1312834973.213:47): arch=c000003e syscall=4 success=no exit=-13 a0=7fb61f6ca930 a1=7fff921a3440 a2=7fff921a3440 a3=0 items=0 ppid=2092 pid=2099 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) type=AVC msg=audit(1312834973.213:47): avc: denied { search } for pid=2099 comm="httpd" name="ulrika" dev=dm-0 ino=4374872 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_dir_t:s0 tclass=dir httpd-2.2.17-10.fc15.1.x86_64 selinux-policy-3.9.16-35.fc15.noarch
Hm..., does "yum remove mod_dnssd gnome-user-share" (as it's described in Comment 11) fix it? We should try to localize, which httpd module is causing it.
I did a quick test, and yes, removing those two packages removes the AVC.
Hm, could you try to keep mod_dnssd there and remove just gnome-user-share? This is probably the last thing we need to point to mod_dnssd.
The problem still exists in Fedora 15. Still automounts all the user homedirs.
With mod_dnssd installed but not gnome-user-share, I still get the AVC:s. As an additional test, I commented out the "LoadModule" line from mod_dnssd.conf, and the AVC:s did disappear. Is it time to reassign this bugzilla to the component mod_dnssd, maybe?
I probably see what's the problem. In mod_dnssd code I see, that "DNSSDAutoRegisterUserDir" is on by default, and it tries to read ~/public_html. Try disabling it by adding this into /etc/httpd/mod_dnssd.conf: DNSSDAutoRegisterUserDir Off Although, I think it should work without selinux AVC even with this feature, so I'm reassigning it to mod_dnssd.
Hmm... I'm not sure that's the only problem. I just check mod_dnssd.conf on my F15 and F14 systems and while that option is "on", it's also commented out (assuming # is indeed a comment for apache).
It's "on" by default, so unless you explicitly write "DNSSDAutoRegisterUserDir Off" there, it's "on".
Gotcha. I'll turn it off then explicitly and see if it fixes it.
I haven't gotten any more sealterts so I would say we have a winner. Is it practical to default this to off in the package?
Or it can be added into selinux-policy, but it more depends on mod_dnssd maintainer.
I'm not sure how it could be done in selinux-policy. I don't want the access allowed, because selinux should protect from that if I haven't intentionally enabled it. I don't want it dontaudited, because if I DO configure httpd to access user's home directories, I want to get the warning if selinux prevents it.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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
These AVC:s still happen in F17 with mod_dnssd-0.6-6.fc17.x86_64.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. 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 '17'. 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 17'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 17 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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 problem remains in mod_dnssd-0.6-8.fc19.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. 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. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.