Red Hat Bugzilla – Bug 238737
-o context=foo for NFS not being applied
Last modified: 2007-11-16 20:14:55 EST
Description of problem: When specifying a context as an option to mount an nfs share after the mount operation is successful, the context is not applied. Version-Release number of selected component (if applicable): nfs-utils-1.0.6-70.EL4 kernel-smp-2.6.9-42.0.10.EL selinux-policy-targeted-1.17.30-2.140 How reproducible: Always. Steps to Reproduce: 1. mount -t nfs -o context=system_u:object_r:httpd_sys_content_t nfs-server:/share /mntpoint 2. ls -dZ /mntpoint Actual results: No SELinux context applied. Expected results: system_u:object_r:httpd_sys_content_t contexts applied Additional info: I'm not sure which component this should be filed under, so my apologies if the selected (nfs-utils) is incorrect. The aforementioned mount command to apply a context to an nfs mount is suggested here... http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/rhlcommon-section-0068.html#RHLCOMMON-SECTION-0097 ...as a workaround for letting Apache execute NFS mounted CGI (which happens to be exactly what I need to do). I've tried both mounting with the options in the command-line and putting them in fstab. When I do an ls -Z on the mount point or the contents, the contexts are blank.
This seems to be broken on RHEL4, but works on RHEL5. strace shows this in this situation: 2773 lgetxattr("/mnt/dantu", "security.selinux", 0x515300, 255) = -1 EOPNOTSUPP (Operation not supported) ...on RHEL5 it works: lgetxattr("/mnt/dantu", "security.selinux", "system_u:object_r:httpd_sys_content_t:s0", 255) = 41
The problem is that NFS doesn't supposed lgetxattr like that. (There is the beginings of work to standardize xattrs over nfs but that work is a long way off) The way the RHEL5 and such work is that there is a VFS special case that if you are trying to look at the security xattrs for selinux it just looks at the in core inode and returns the sid rather than actually calling into the FS xattr handler. RHEL4 doesn't have this hook so it have no way to return the context. The above mount is actually working and mounting with the giving context (note when you mount dmesg says it is a context mount point labeling rather than genfs) The best way on RHEL4 to see the context to to get a denial when accessing it. Yeah, its not pretty and i'll take a look at what it would take to backport the vfs special casing to RHEL4 (which would show contexts on everyhting like proc and sys and things like that) but for now this is working and working as expected. Just hard to look at what they are... -Eric
Thanks for the explanation. I'm more interested in the functionality than the appearance, so feel free to close this as notabug (I tried, but got denied).
If you are happy, I am happy :)