Bug 120290 - NFS errors from server in enforcing mode
NFS errors from server in enforcing mode
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: James Morris
Ben Levenson
:
Depends On:
Blocks: 122683
  Show dependency treegraph
 
Reported: 2004-04-07 12:07 EDT by Tim Waugh
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version: current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-15 23:35:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Tim Waugh 2004-04-07 12:07:25 EDT
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 15:04:19 EDT
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 04:34:23 EDT
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 08:38:10 EDT
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 08:42:04 EDT
Note:

192.168.17.90 is the server
192.168.17.60 is the client
Comment 5 Russell Coker 2004-09-28 22:23:53 EDT
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 15:07:58 EST
Fixed in FC3.
Comment 7 Leos Bitto 2005-09-03 21:13:36 EDT
(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 17:23:48 EDT
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 02:24:03 EDT
(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 09:52:15 EDT
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 11:35:33 EDT
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 11:46:23 EDT
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 12:34:55 EDT
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-15 23:35:56 EDT
Closing several old modified bugs

Note You need to log in before you can comment on or make changes to this bug.