Bug 238737 - -o context=foo for NFS not being applied
Summary: -o context=foo for NFS not being applied
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.4
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Eric Paris
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-02 17:57 UTC by Jason Bradley Nance
Modified: 2007-11-17 01:14 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-09-10 19:41:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Jason Bradley Nance 2007-05-02 17:57:05 UTC
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.

Comment 1 Jeff Layton 2007-07-20 13:42:06 UTC
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



Comment 4 Eric Paris 2007-07-30 19:46:29 UTC
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

Comment 5 Jason Bradley Nance 2007-07-30 23:56:38 UTC
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).

Comment 6 Eric Paris 2007-09-10 19:41:12 UTC
If you are happy, I am happy  :)


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