Red Hat Bugzilla – Bug 150738
avc denied nfsd associate access to nfs mountpoint that is mountpoint labeled
Last modified: 2007-11-30 17:07:16 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: <mountopint>/<subdirectory> 192.168.3.27(rw,sync) 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 tclass=filesystem Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.30-2.52.1 How reproducible: Always 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 tclass=filesystem access is denied to client machine Expected Results: no error Additional info: Changing to permissive allows things to work correctly.
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. Dan
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 RHEL4. 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.
Ok, the best thing to do would be to pick say usr_t as the mount point and try that. Dan
I changed fstab to: context=user_u:object_r:usr_t 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.
Ok one last try. Use scontext user_u:object_r:nfs_t for you context mount point.
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?
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. Dan
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
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?
The problem went away after: I tried another kernel (custom 2.6.11.12). With enforcing disabled from the gui security tool with the 2.6.9-5.0.5.EL kernel. Went back to enforcing set from the gui security tool with the 2.6.9-5.0.5.EL kernel. In fact, now it always works correctly, enforcing or not, with the current kernel. 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.
So this now sounds like an NFS problem.