Bug 120290
Summary: | NFS errors from server in enforcing mode | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> |
Component: | nfs-utils | Assignee: | James Morris <jmorris> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ben Levenson <benl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | bitto, dwalsh, gczarcinski, mkearey |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | current | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-03-16 03:35:56 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: | |||
Bug Depends On: | |||
Bug Blocks: | 122683 |
Description
Tim Waugh
2004-04-07 16:07:25 UTC
The failure doesn't happen after 'setenforce 0; service nfs restart'. So it happens in enforcing mode, but not in permissive mode. If this is really a selinux problem (and it certainly looks that way since it works OK in permissive mode), I suspect it should be reported against policy and not nfs-utils. Therefore, I am adding Dan Walsh to the CC list. This has nothing to do with the install and can be easier debugged with just doing a mount from another system. This is also more likely policy. OK, I did the following: 1. setenforcing 0 2. /etc/init.d/nfs start 3. setenforcing 1 4. from another system try to mount nfs volume on the system running nfs From that system's /var/log/messages, I get the following: Apr 16 08:38:37 chaos kernel: audit(1082119117.320:0): avc: granted { setenforce } for pid=18157 exe=/usr/bin/setenforce scontext=root:sysadm_r:sysadm_t tcontext=system_u:object_r:security_t tclass=security Apr 16 08:38:58 chaos kernel: audit(1082119138.383:0): avc: denied { read } for pid=18129 comm=nfsd laddr=192.168.17.90 lport=2049 faddr=192.168.17.60 fport=619 scontext=system_u:system_r:kernel_t tcontext=system_u:object_r:unlabeled_t tclass=file Apr 16 08:38:58 chaos kernel: nfsd: recvfrom returned errno 13 Apr 16 08:38:58 chaos kernel: nfsd: terminating on error 13 Apr 16 08:39:07 chaos kernel: audit(1082119147.353:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:07 chaos kernel: audit(1082119147.554:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:07 chaos kernel: audit(1082119147.956:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:08 chaos kernel: audit(1082119148.760:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:10 chaos kernel: audit(1082119150.367:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:13 chaos kernel: audit(1082119153.583:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:20 chaos kernel: audit(1082119160.014:0): avc: denied { rawip_recv } for pid=15484 exe=/usr/X11R6/bin/Xorg saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Apr 16 08:39:32 chaos kernel: audit(1082119172.876:0): avc: denied { rawip_recv } for saddr=192.168.17.60 src=619 daddr=192.168.17.90 dest=2049 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Note: 192.168.17.90 is the server 192.168.17.60 is the client It looks like the system used for reporting this bug was messed up. Lots of files and processes have type unlabeled_t. If this still occurs then please add a comment with the AVC messages from a working system in enforcing mode. Fixed in FC3. (In reply to comment #6) > Fixed in FC3. Was this fixed properly for RHEL4 too? I am running RHEL 4 ES Update 1 with all errata applied and yet I have received these two messages from SELinux in enforcing mode with the targeted policy: audit(1125272367.492:0): avc: denied { rawip_recv } for pid=3869 comm=fping saddr=192.168.100.55 daddr=a.b.c.d netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif audit(1125272847.105:0): avc: denied { rawip_recv } for pid=1696 comm=named saddr=192.168.100.163 daddr=a.b.c.d netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif Both those IP packets are valid, a.b.c.d is a public IP address of this server. I run fping to monitor reachability of some hosts in the internal network and this server acts as a nameserver for many clients in the internal network. Not being able to process those two packets did not hurt, but I am afraid that I could loose more important data in the future... This looks like a labeling problem. Somehow your machine is mislabeled. To relabel touch /.autorelabel reboot Will clean it up. (In reply to comment #8) > This looks like a labeling problem. Somehow your machine is mislabeled. To > relabel > touch /.autorelabel > reboot > Will clean it up. Are you sure that this will not clean up too much? I have quite a lot of preciously tuned stuff (httpd_sys_script_ro_t, httpd_sys_script_rw_t, etc.) and I would hate to loose it. If you could suggest what exactly should I relabel (using restorecon?) I would feel much safer. I have a change that is going into initscripts to fix this. For now if you change the line in /etc/rc.sysinit to fixfiles restore instead of fixfiles -f -F relabel. It will preserve your customizables. Or execute fixfiles restore as root. Being cautious, I have executed "fixfiles check" only, and nothing was shown. I really do not want to mess up my production server (it's RHEL4, not Fedora), so I have filed a support request at http://www.redhat.com/support (#672092) and I hope that I will get some help from there. Ok rereading this, it looks like a problem, with an process running as unlabeled_t which should never happen. Have you rebooted the machine? Dan Sure I have rebooted the machine. Last time 66 days ago. Running ps xaZ | grep unlabeled shows only onle line - grep unlabeled. Neither dovecot nor named have been restarted recently. Dovecot runs unconfined_t, named runs named_t. Closing several old modified bugs |