This is version 5 of the NFSv3 XATTR protocol extension patches, which I've previously posted as: v1: http://thread.gmane.org/gmane.linux.file-systems/35475 v2: http://thread.gmane.org/gmane.linux.nfs/30539 v3: http://thread.gmane.org/gmane.linux.nfs/30971 v4: http://thread.gmane.org/gmane.linux.kernel.lsm/10562 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: http://namei.org/nfsv3xattr/v05/userspace/ 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: http://namei.org/nfsv3xattr/v05/policy/ 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. Comments welcome. - James -- James Morris <jmorris@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
