On Fri, 2010-02-26 at 15:37 +1100, James Morris wrote: > Add support for a server namespace for storing and retrieving > client-supplied xattrs. All xattrs are now stored on the server under > the user._nfsd namespace, and are not interpreted by the server at all. > This allows clients to utilize arbitrary xattr namespaces and for the > server to act only as a storage mechanism for the xattrs. > > The user._nfsd namespace was chosen because filesystems generally have > a user. xattr handler implemented. Using something like system. would > require implementing a generalized handler for each backing fs on the > server, as well as requiring privilege to access. I'm wondering whether the user. namespace is best for storage on the server given that: - the user. namespace is restricted to regular files or directories (see xattr_permission()), and - the user. namespace applies its own set of permission checking logic that we don't necessarily want applied in the case of trusted. or security. attributes (e.g. special rules on sticky directories and read or write access to the file, see xattr_permission()), and - storing the attributes in the user. namespace would allow local users on the server to manipulate them directly. I know that you stated an assumption that end users do not have local access to the exported filesystem, but it would be better if the system itself would restrict the ability to set these attributes to privileged processes on the server. Using the security. or trusted. namespace would avoid the restriction on file type and require CAP_SYS_ADMIN on setxattr. That would prevent local modification by non-admins and should have no effect on clients (since nfsd doesn't drop CAP_SYS_ADMIN). > Currently, only the user and trusted namespaces are supported by > the client, as system and security namespaces require further analysis, > and some special-case handling will be required (for security.selinux, > at least). > > NFS ACLs continue to work as expected, because they implement a > hard-coded system xattr namespace which is invoked before the > NFS layer. e.g. any access to a system.posix_acl_access xattr > is invokes the NFS_ACL protocol. -- Stephen Smalley National Security Agency -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
