Bug 120290

Summary: NFS errors from server in enforcing mode
Product: [Fedora] Fedora Reporter: Tim Waugh <twaugh>
Component: nfs-utilsAssignee: James Morris <jmorris>
Status: CLOSED CURRENTRELEASE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: 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
Description of problem:
When trying to install over NFS from a server running current rawhide
in enforcing mode, the install aborts because of NFS errors caused by
the server.  The precise timing varies.

Version-Release number of selected component (if applicable):
kernel-2.6.4-1.305
policy-1.10.1-2
nfs-utils-1.0.6-19.fc2

How reproducible:
100%

Steps to Reproduce:
1. Probably should be sufficient to try copying an entire install tree
from a rawhide NFS server (running in enforcing mode).

Example tcpdump output of first error:

14:35:02.034154 IP 192.168.1.1.2049 > 192.168.1.7.490739511: reply ERR
20 read [|nfs]

192.168.1.1 is the server.

I haven't tried 'setenforce 0; service nfs restart' yet, but will soon.

Comment 1 Tim Waugh 2004-04-07 19:04:19 UTC
The failure doesn't happen after 'setenforce 0; service nfs restart'.
 So it happens in enforcing mode, but not in permissive mode.

Comment 2 Gene Czarcinski 2004-04-15 08:34:23 UTC
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.

Comment 3 Gene Czarcinski 2004-04-16 12:38:10 UTC
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


Comment 4 Gene Czarcinski 2004-04-16 12:42:04 UTC
Note:

192.168.17.90 is the server
192.168.17.60 is the client

Comment 5 Russell Coker 2004-09-29 02:23:53 UTC
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. 

Comment 6 Daniel Walsh 2004-12-02 20:07:58 UTC
Fixed in FC3.

Comment 7 Leos Bitto 2005-09-04 01:13:36 UTC
(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...

Comment 8 Daniel Walsh 2005-09-06 21:23:48 UTC
This looks like a labeling problem.  Somehow your machine is mislabeled.  To
relabel 

touch /.autorelabel
reboot

Will clean it up.

Comment 9 Leos Bitto 2005-09-07 06:24:03 UTC
(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.

Comment 10 Daniel Walsh 2005-09-07 13:52:15 UTC
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.

Comment 11 Leos Bitto 2005-09-07 15:35:33 UTC
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.

Comment 12 Daniel Walsh 2005-09-07 15:46:23 UTC
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

Comment 13 Leos Bitto 2005-09-07 16:34:55 UTC
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.

Comment 14 Daniel Walsh 2007-03-16 03:35:56 UTC
Closing several old modified bugs