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