Re: [PATCH 5/5] NFSv3: Add server namespace support for XATTR protocol implementation

[Stephen Smalley <sds@tycho.nsa.gov>]

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