Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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 |