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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 8 Mar 2010, Brad Boyer wrote:

> I personally think it's a bad idea to not map regular user xattr values
> directly to what is local to the server. One common thing I've seen in
> many places is to have local disks on various servers exported over
> NFS to other servers, but the intent is that the user shouldn't care
> which server physically hosts the storage. In this case, you want the
> data to appear the same regardless of the use or non-use of NFS. In
> this sort of situation, one system will see different data than the
> others for the same files with the same access level. One possible
> option would be to make it configurable, kind of like root_squash.

It should be straightforward to make it configurable, although I wonder if 
this might end up leading to more confusion for admins.  They'll always 
have to remember how they exported each filesystem.  If they ever mount a 
filesystem with the wrong option, and users start accessing it, they could 
end up with an unfixable mess.

The core issue is that we don't want system-level xattrs being stored on 
the server.

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.

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?



- James
-- 
James Morris
<jmorris@xxxxxxxxx>
--
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

[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux