Re: [PATCH 0/6][v4][RFC] NFSv3: implement extended attribute protocol (XATTR)

Brad Boyer
2010-03-13T07:28:59Z

On Tue, Mar 09, 2010 at 07:13:45PM +1100, James Morris wrote:
> The core issue is that we don't want system-level xattrs being stored on
> the server.

I can understand that, but it does seem like only system xattrs should
be treated that way to me.

> As you suggest, perhaps we always leave 'user' xattrs untranslated on the
> server, with an expectation that they're always opaque to the server and
> managed entirely by user applications.

This seems reasonable.

> I don't think we can meaningfully do this for 'trusted' xattrs, as we
> don't know how to extend CAP_SYS_ADMIN over NFS. So, this, and all other
> non-user namespaces (e.g. 'system', 'security') are mapped on the server
> to the 'nfsd' namespace, on the basis that they would otherwise require
> interpretation by the server, which we want to avoid. (Note that there's
> an exception here for POSIX ACLs, which already use a well-defined
> protocol over NFS).
>
> Here's a summary of the mappings:
>
> Client Server
>
> user.a user.a
> trusted.a nfsd.trusted.a
> system.a nfsd.system.a
> security.a nfsd.security.a
>
> Special cases:
>
> if ACL protocol enabled on server:
>
> system.posix_acl_access system.posix_acl_access
> system.posix_acl_default system.posix_acl_default
>
> if ACL protocol not enabled on server:
>
> system.posix_acl_access [error]
> system.posix_acl_default [error]
>
> This also ensures that nothing about the existing NFS ACL support changes.
>
> 'user' xattrs simply work as expected, whether accessed locally or
> remotely.
>
> How does this sound?

This mapping sounds great to me. It would be interesting to hear some
opinions from other people on the lists.

Brad Boyer
flar@allandria.com