Bug 150738 - avc denied nfsd associate access to nfs mountpoint that is mountpoint labeled
avc denied nfsd associate access to nfs mountpoint that is mountpoint labeled
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: selinux-policy-targeted (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-03-09 21:59 EST by Mark Goldberg
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.6.9-5.0.5.EL
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-25 10:56:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Goldberg 2005-03-09 21:59:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1 Red Hat/1.0.1-1.4.3

Description of problem:
fstab contains an entry like:

/dev/hdd5  <mountpoint>  ext3    context=user_u:object_r:default_t    0 0

exports contains an entry like:


another machine mounts the nfs mountpoint and can see the contents, but
any attempt to create a new file or directory results in errors like:

avc:  denied  { associate } for  pid=4804 comm=nfsd name=deletemefolder
scontext=user_u:object_r:default_t tcontext=user_u:object_r:default_t

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

How reproducible:

Steps to Reproduce:
1. mount the disk
2. share via nfs
3. mount the nfs share from another computer
4. attempt to create a new file on the share


Actual Results:  Errors like:

avc:  denied  { associate } for  pid=4804 comm=nfsd name=deletemefolder
scontext=user_u:object_r:default_t tcontext=user_u:object_r:default_t

access is denied to client machine

Expected Results:  no error

Additional info:

Changing to permissive allows things to work correctly.
Comment 1 Daniel Walsh 2005-03-09 23:48:58 EST
Why are you useing a context mount.  You should not be doing this.

Is the file system unlabeled?

Remove the context and see if you still get errors.

Comment 2 Mark Goldberg 2005-03-10 13:03:00 EST
The old file system is used by a previous (production) installatiion
of RHEL3 that does not have selinux, so it is unlabelled. Until
I get RHEL4 completely up and running and providing the same
services to the network as RHEL3, I can't switch over and don't
want to disturb the old file system too much. If I then mount
it again with RHEL3, it will mess up the extended attributes
and it will have to be relabelled every time I reboot into

The good news is that this is not a showstopper, but I cannnot
do the test you ask until I retire the old installation.
t may take several weeks until the RHEL4 takes over
and I retire the old installation. I am bringing up the services
one at a time and can only do it during network downtime.

I can and will create an additional nfs mountpoint on the labelled
file system and retest. 
Comment 3 Daniel Walsh 2005-04-21 12:23:53 EDT
Ok, the best thing to do would be to pick say usr_t as the mount point and try that.

Comment 4 Mark Goldberg 2005-04-24 14:37:13 EDT
I changed fstab to:


It acts the same with errors like:

avc:  denied  { associate } for  pid=3660 comm=nfsd name=deleteme1
scontext=user_u:object_r:usr_t tcontext=user_u:object_r:usr_t tclass=filesystem

Creating and using an nfs mount on the labeled file system works fine.

For now, I still need to leave it permissive.

I still think this should be able to work without leaving the whole system
permissive. It is not unusual to have a share come from some file system that
does not support xattr and needs to be context mounted.
Comment 5 Daniel Walsh 2005-04-25 10:52:16 EDT
Ok one last try.  

Use scontext user_u:object_r:nfs_t for you context mount point.
Comment 6 Mark Goldberg 2005-05-01 01:30:26 EDT
This seems to work. Sharing via Samba and nfs seem to work fine. Files and
directories can be created, renamed, edited and deleted. I will let you know
if there are any other problems. This also seems to work from the local
login on the server computer, files can also be used on the shared drives. 

Where can I see what nfs_t specifies?
Comment 7 Daniel Walsh 2005-05-02 07:27:16 EDT
You can read policy sources.  

nfs_t basically sets up a security context that users can read/write/execute by
default.  It is obviously used for remote nfs file systems that do not support
labeleing.  But it can be used for a generic labeling to get the desired behaviour.

Comment 8 Mark Goldberg 2005-06-04 11:56:21 EDT
I just noticed that the following errror comes up on startup.
It takes several minutes for nfs to start and I get rpc timeout
errors reported on the first connection from a remote user.
System otherwise works afterwards, but nfs mounts and unmounts
from a remote user are slow.

I do not know when this started, but it might have started after
updating to the latest kernel 2.6.9-5.0.5.EL.

kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
kernel: SELinux: initialized (dev nfsd, type nfsd), uses genfs_contexts
nfs: Starting NFS services:  succeeded
nfs: rpc.rquotad startup succeeded
nfs: rpc.nfsd startup succeeded
kernel: svc: bad direction 65536, dropping request
kernel: svc: bad direction 65536, dropping request
ntpd[2919]: kernel time sync disabled 0041
nfs: rpc.mountd startup succeeded
rpcidmapd: rpc.idmapd -SIGHUP succeeded

Comment 9 Daniel Walsh 2005-06-06 11:02:22 EDT
Are  you seeing avc messages in /var/log/messages or /var/log/audit/audit.log?

If you type setenforce 0, does the problem go away?

Comment 10 Mark Goldberg 2005-06-08 10:29:20 EDT
The problem went away after:

I tried another kernel (custom

With enforcing disabled from the gui security tool with the 2.6.9-5.0.5.EL

Went back to enforcing set from the gui security tool with the 2.6.9-5.0.5.EL

In fact, now it always works correctly, enforcing or not, with the current

The nfs connections are now as fast as they were before.

The messages before were from /var/log/messages with the prefix listing
the machine name stripped off. There is no /var/log/audit/audit.log.
Comment 11 Daniel Walsh 2005-06-08 11:06:29 EDT
So this now sounds like an NFS problem.

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