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

[Brad Boyer <flar@allandria.com>]

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