|| ||James Morris <firstname.lastname@example.org> |
|| ||email@example.com |
|| ||[PATCH 0/8][v05][RFC] NFSv3: implement extended attribute protocol (XATTR) |
|| ||Mon, 21 Jun 2010 21:25:56 +1000 (EST)|
Trond Myklebust <Trond.Myklebust@netapp.com>,
"J. Bruce Fields" <firstname.lastname@example.org>,
Neil Brown <email@example.com>, firstname.lastname@example.org,
Stephen Smalley <email@example.com>|
|| ||Article, Thread
This is version 5 of the NFSv3 XATTR protocol extension patches, which
I've previously posted as:
In the previous version, I implemented a new top-level xattr namespace on
the server, which is used to store client-supplied xattrs, e.g.:
client: user.a -> server: nfsd.user.a
In this version, I've enhanced support for security xattrs, and updated
SELinux so that it can utilize the XATTR protocol for security labeling.
I added a new NFS error code, NFSERR_NODATA, so that we can cleanly handle
cases where the xattr system calls on the server return -ENODATA to
indicate a non-existent xattr (this is often not an error condition).
Also new are the xattr and xattrsec mount options, which are used to
control the use of the XATTR protocol and XATTR security labeling
respectively (see patch #7).
The userspace patch for the mount utility is available at:
The XATTR code also now calls back into the LSM during file creation so
that an appropriate security label may be installed at the same time
(atomically from the client pov). This follows the behavior of the ACL
code (see nfs3_init_xattr() in patch #6).
For SELinux, the approach is to allow both genfs (the current labeling
behavior) and xattr labeling. To support the latter, an fs_use_xattr
statement needs to be added to policy for NFS:
By default, mounts will still use genfs, unless the admin also supplies
the new 'xattrsec' mount option, to indicate to the security module that
it should use the XATTR protocol for labeling. If XATTR is unavailable,
the mount will fail (and not fall back to genfs).
This code still has several major todo items (mostly marked in the code),
and needs much more testing, although I'd like to get feedback from the
NFS and security folk on the current approach.
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html