Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157898 - NFS server blocked by SELinux causes client to hang
Summary: NFS server blocked by SELinux causes client to hang
Alias: None
Product: Fedora
Classification: Fedora
Component: nfs-utils
Version: 4
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-16 20:48 UTC by Göran Uddeborg
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-12-07 01:57:55 UTC

Attachments (Terms of Use)

Description Göran Uddeborg 2005-05-16 20:48:46 UTC
Description of problem:
Accessing a directory which the NFS server isn't allow to read because of
SELinux causes the client to hang indefinitely.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Export root file system on the server: 
   22:28 freddi### cat /etc/exports
2. Mount that file system on the client:
   22:34 mimmi> tail -1 /etc/fstab
   freddi:/                  /mnt/remote/freddi     nfs  noauto,intr 0 0
3. List the server's /usr/src from the client:
   22:34 mimmi> \ls /mnt/remote/freddi/usr/src
Actual results:
The ls process hangs indefinitely:
   mimmi> ps -C ls -lw
   0 S   503 16397 12822  0  76   0 -  1043 rpc_ex pts/1    00:00:00 ls
On the server, there is an audit log entry:
   type=KERNEL msg=audit(1116274920.083:0): avc:  denied  { search } for 
name=src dev=sda2 ino=2322119 scontext=system_u:system_r:nfsd_t
tcontext=system_u:object_r:src_t tclass=dir

Expected results:
An error message.  If the NFS server isn't allowed to fulfill the request, it
should say so.

Additional info:
I'm just starting to explore SELinux, and I'm not sure if it really is
correct that the nfs daemon is disallowed to look in /usr/src.  It seems odd
but I'm not sure.  But in any case, if that is wrong, that is an independent

Comment 2 James Morris 2005-05-18 13:00:38 UTC
Are there any further AVC messages?

Looks like the kernel code (related to rpc_execute()) is not handling the error

Comment 3 Stephen Smalley 2005-05-18 13:22:48 UTC
With regard to the policy, there are booleans that control nfsd's access, and
the targeted policy seems to enable them by default in its booleans file.
Run /usr/sbin/getsebool nfs_export_all_ro nfs_export_all_rw or use
system-config-securitylevel GUI to inspect.

What happens if you chmod 0 /usr/src on the server and try accessing it from the
client w/ SELinux in permissive mode (setenforce 0)?  I'd expect them to have
similar behavior, as the DAC search check should fail in that case, right?  nfsd
should be running with the fsuid of the client process at that point, right, so
an access denial is possible here even without SELinux?

Comment 4 Göran Uddeborg 2005-05-18 22:36:52 UTC
When I was testing to answer your questions, I found out that the situation was
a bit more complicated than I first realised.  The hang occurs when I try to
list a directory which on the server is in turn NFS mounted.  I.e, if on the client:

   freddi:/ on /mnt/remote/freddi type nfs (rw,intr,addr=

and on the server:

   mimmi:/usr/src/redhat on /usr/src/redhat type nfs (rw,bg,addr=

then this hangs when I run this on the client (mimmi):

   \ls /mnt/remote/freddi/usr/src/redhat

(This is NFSv3, so the directory "redhat" should be empty when seen from the

Now, to the specific questions:

1. There are no further AVC messages.  (They always wind up in audit.log, right?
 Or should I look in more places?)  There are two other audit messages at the
same time.  I don't know if they are relevant.

type=KERNEL msg=audit(1116454260.708:954803): avc:  denied  { search } for 
name=src dev=sda2 ino=2322119 scontext=system_u:system_r:nfsd_t
tcontext=system_u:object_r:src_t tclass=dir
type=KERNEL msg=audit(1116454260.708:954803): item=0 inode=2322119 dev=08:02
mode=040755 uid=0 gid=0 rdev=00:00
type=KERNEL msg=audit(1116454260.708:954803): syscall=4 exit=-13 a0=f7fe1000
a1=2a a2=2a a3=0 items=1 pid=2316 loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 comm=rpc.mountd exe=/usr/sbin/rpc.mountd

"auditctl -t 4", which I belive is what I should do to decode the syscall
number, replies "arch:x86_64, syscall:stat"

2. About the bools:
freddi### getsebool nfs_export_all_ro nfs_export_all_rw
nfs_export_all_ro --> inactive
nfs_export_all_rw --> inactive

3. If I change the directory to mode 0 and run in permissive mode, I get a
"Permission denied" when running "ls".

I'm sorry my original report didn't include those bits about the NFS mount.  I
didn't realise the connection.

Comment 5 Stephen Smalley 2005-05-19 12:12:56 UTC
The audit message shows that rpc.mountd is attempting to stat /usr/src/redhat
and is failing on the attempt to search /usr/src due to the booleans being
inactive (they should be active by default in targeted policy, see
/etc/selinux/targeted/booleans and /etc/selinux/targeted/booleans.local; change
via /usr/sbin/setsebool -P or system-config-securitylevel GUI).
I'm a little unclear as to why rpc.mountd is involved at this point, as this is
occuring upon an attempted lookup after a mount of a higher level directory.  I
would have expected the denial to occur on nfsd itself instead.
Looking at the credentials in the audit message, I see that fsuid=0, so DAC
would not deny access; only SELinux could trigger a denial here.  Still seems
like a bug in the error handling code in nfs, as this could always fail due to
some other issue (e.g. EIO).

Comment 6 Göran Uddeborg 2005-05-19 21:51:16 UTC
In summary, this is a confirmation of what you say in comment 5.

There was indeed a booleans.local which disabled those booleans.  I don't know
when or how I got it there.  But I've been trying to get to know SELinux,
O'Reilly's book in one hand and an FC4 test sytem under the other.  I've mostly
looked so far, not changed, but I probably did something along the way which
caused this.

I tried to remove the booleans.local completely and reboot.  As you said, I
don't get any denial then.  getsebool confirms the two booleans are active now.

I guess it's not too suprising if rpc.mountd isn't prepared to handle a
"permission denied", as it's normally run as root.  I too wonder why it is
involved.  And it looks like a bug to me too.

I did one further observation.  It seems to be the conditions the first time the
client tries to access the directory which decides if this problem occurs or
not.  If I first do an "ls" on the client with the booleans active, and then
change them to inactive, I can still do the "ls".  I have not extensively
checked all combinations (permissive/enforcing, booleans on/off, etc), but that
seems to be a pattern.  Maybe that can be a clue to someone who understands how
NFS works better than I do?

Comment 7 Steve Dickson 2005-05-23 12:11:32 UTC
Maybe I'm missing something... but if I read the first comment
correctly, your exporting an nfs mounted filesystem which
is something that *shouldn't* work....

Unfortunately, I don't have a FC4 machine handy but
using a FC3 client, RHEL3 server (exporting an NFS fs)
and another RHEL4  (exporting ext3 fs) I get a
"permission denied" when I do the mount from the FC3 client.
(rightly so since the RHEL3 server is denying access to that
export .)

Again, unless I'm missing something, I shocked the mount
is even working and the real bug, imho, is that exportfs allows
the exporting of NFS mounted filesystems...

Comment 8 Göran Uddeborg 2005-05-25 21:36:33 UTC
I've been trying different test cases while trying to understand this, and maybe
my comments taken together are confusing.  I'm sorry for that.  I am not (aware
that I am) exporting NFS mounted file systems.  The test case I'm using now is this:

- Two machines, mimmi and freddi
- freddi mounts mimmi:/usr/src/redhat on /usr/src/redhat
- mimmi mounts freddi:/ on /mnt/remote/freddi
- on freddi: setsebool nfs_export_all_ro=0 nfs_export_all_rw=0
- on mimmi: ls /mnt/remote/freddi/usr/src/redhat

The last command hangs on mimmi, and triggers the three audit messages in comment 4.

So what I'm doing is that I from mimmi try to list the directory which on freddi
is a mount point for an NFS file system.  But this is NFSv3 so I should not see
the file system mounted there, just the empty directory.  And that is indeed
what I see if I set the booleans to their default value true.  (Or run in
permissive mode).

Comment 9 Göran Uddeborg 2005-05-26 20:51:29 UTC
In case it is of any help, I realised one could trigger this with only one
machine, NFS mounting from itself.  Here is a simplified test case:

- One machine with FC4t3, including the NFS service.
- mkdir /tmp/test
- exportfs -o rw localhost:/
- mount localhost:/ /mnt/test
- setsebool nfs_export_all_ro=0 nfs_export_all_rw=0
- ls /mnt/test/mnt/test

As before, the ls command hangs indefinitely in an uninterruptible sleep.

Comment 10 Daniel Walsh 2005-06-08 16:12:09 UTC
I don't see this as a bug that will be fixed.  Basically you allowing a mount in
NFS and then yanking the covers out from under it.  It is understandably
confused and not likely to recover.


Comment 11 Göran Uddeborg 2005-06-08 20:40:36 UTC
Do you in comment 10 refer to the fact that I set the booleans after the mount?  

If so, let me point out that the mount is not affected by these booleans.  You
can change the test case by doing the setsebool first.  Even before starting the
nfs service is started if you want.  Then do the remaining steps, all with those
booleans cleared.  The end result is still an ls hanging indefinitely in
uninterruptible sleep.

(I wrote /tmp/test rather than /mnt/test in the mkdir command I see now.  That
was just a mistake of course.  I meant /mnt/test all the way.)

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