From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20050104 Red Hat/1.4.3-3.0.7 Description of problem: With NFS homes directories auto-mounted from an RHEL 3 AS file server onto a RHEL 4 AS web server, UserDir public_html fails unless SELinux is disabled. Version-Release number of selected component (if applicable): httpd-2.0.52-9.ent How reproducible: Always Steps to Reproduce: 1. Enable UserDir in httpd.conf 2. Point a browser at a user's pages (e.g. www.cmmp.ucl.ac.uk/~lkd) 3. Actual Results: 403 error. Expected Results: See user's front page. Additional info: Error in the logs is: Mar 1 13:28:28 metatron kernel: audit(1109683708.145:0): avc: denied { search } for pid=3389 exe=/usr/sbin/httpd name=/ dev=autofs ino=5269 scontext=root:system_r:httpd_t tcontext=system_u:object_r:autofs_t tclass=dir Mar 1 13:28:28 metatron kernel: audit(1109683708.145:0): avc: denied { getattr } for pid=3389 exe=/usr/sbin/httpd path=/homes dev=autofs ino=5269 scontext=root:system_r:httpd_t tcontext=system_u:object_r:autofs_t tclass=dir
Thanks for the report. This seems to be a bug in the SELinux targeted policy; it should be allowing those accesses.
To confirm that: an updated version of the SELinux targeted policy which fixes this issue is available for testing purposes, from: ftp://people.redhat.com/dwalsh/SELinux/RHEL4/selinux-policy-targeted-1.17.30-2.86.noarch.rpm This fix is targeted to be included in U1.
I'm getting: Usage: /sbin/fixfiles {-R rpmpackage[,rpmpackage...] [-l logfile ] [-o outputfile ] |check|restore|[-F] relabel} when installing the selinux-policy-targeted-1.17.30-2.86.noarch.rpm.
You need to update the policycoreutils. It should have been required. Dan
I've checked ftp://ftp.redhat.com/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/, and there's no update for policycoreutils. I'll try compiling the one from FC3.
ftp://people.redhat.com/dwalsh/SELinux/RHEL4/policycoreutils-1.18.1-4.3.i386.rpm Is the one scheduled for U1
Installing these two packages solves the autofs bug, but causes a new breakage with minilogd, and still leaves httpd and syslogd unable to write to their output files. ntpd is also still unable to read its drift file (should I file these as seperate bugs?)... From dmesg: audit(1110789131.039:0): avc: denied { read } for pid=590 exe=/sbin/minilogd name=ld.so.cache dev=hda2 ino=33264 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:file_t tclass=file
Created attachment 111969 [details] diff of dmesg outputs Attached a diff of dmesg outputs related to selinux (By doing # dmesg | grep 'security\|SELinux\|audit' > dmesg_new_policy repeated after reinstalling old policycoreutils and selinux-policy-targetted to create dmesg_old_policy, then diff -u dmesg_old_policy dmesg_new_policy > newpolicy_effects Points to note are the fixing of the autofs bug and the new minilogd error.)
Are these new selinux-related problems caused by running with SELINUX=disabled while waiting for this autofs fix? It occurs to me (selinux dunce that I am) that the contexts might be screwed up by having written to each of these files over the last few days. If so, any ideas on the correct invocation of chcon necessary to fix them?
Yes, if you run with SELINUX=disabled, you need to relabel your filesystem before returning to enforcement. touch /.autorelabel reboot
The fix works - thanks. autorelabel re-exposes the subdirectories problem (bug # 149990), but that's easily fixed.
Spoke too soon: autorelabel also leaves suexec inopperable, presumably because it has the wrong contexts. This breaks our perl scripts, and I don't know and can't find info on the correct settings. Any suggestions? ls -lZ /usr/sbin/suexec -r-s--x--- root apache system_u:object_r:httpd_suexec_exec_t /usr/sbin/suexec audit(1110882504.941:0): avc: denied { net_bind_service } for pid=25469 exe=/usr/sbin/suexec capability=10 scontext=root:system_r:httpd_suexec_t tcontext=root:system_r:httpd_suexec_t tclass=capability audit(1110882504.941:0): avc: denied { write } for pid=25469 exe=/usr/sbin/suexec name=httpd dev=hda9 ino=131086 scontext=root:system_r:httpd_suexec_t tcontext=system_u:object_r:httpd_log_t tclass=dir