ACLs

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
Line 11: Line 11:
Basic design of the linux implementation:
Basic design of the linux implementation:
-
On the server side, we have a problem, because none of the filesystems we export support NFSv4 ACLs.  However, many of them do support POSIX ACLs.  So we map NFSv4 ACLs to POSIX ACLs and store POSIX ACLs in the filesystem.  The mapping is imperfect, and prevents the server from accepting the full range of NFSv4 ACLs.  We could instead store NFSv4 ACLs somewhere else--say in a separate extended attribute used only by the NFSv4 server.  However, this would prevent our ACLs from being enforced against local users of the same filesystem.
+
None of the filesystems which the linux server exports support NFSv4 ACLs.  However, many of them do support POSIX ACLs.  So we map NFSv4 ACLs to POSIX ACLs and store POSIX ACLs in the filesystem.  The mapping is imperfect, and prevents the server from accepting the full range of NFSv4 ACLs.  We could instead store NFSv4 ACLs somewhere else--say in a separate extended attribute used only by the NFSv4 server.  However, this would prevent our ACLs from being enforced against local users of the same filesystem.  The code to perform this mapping on the server side is in the kernel, in fs/nfsd/nfs4acl.c.
-
The code to perform the mapping on the server side is in the kernel, in fs/nfsd/nfs4acl.c.
+
The client also maps between NFSv4 and POSIX ACLs on the client, to allow it to support existing POSIX ACL interfaces.  However it does this mapping in userspace; the kernel deals only in NFSv4 ACLs, which it exposes through a special extended attribute ("system.nfs4_acl").  Applications that use the POSIX ACL interfaces need to use a version of libacl that has been modified to do POSIX<->NFSv4 ACL mapping.  But since userspace also has full access to the raw NFSv4 ACL, we can also provide utilities that get and set NFSv4 ACLs directly, without the need for mapping.
-
 
+
-
To allow the client to support existing POSIX ACLs interfaces, we also map between NFSv4 and POSIX ACLs on the client.  However we does this mapping in userspace; the kernel deals only in NFSv4 ACLs, which it exposes through a special extended attribute ("system.nfs4_acl").  Applications that use the POSIX ACL interfaces need to use a version of libacl that has been modified to do POSIX<->NFSv4 ACL mapping.  But since userspace also has full access to the raw NFSv4 ACL, we can also provide utilities that get and set NFSv4 ACLs directly, without the need for mapping.
+
The data in the system.nfs4_acl attribute consists of the raw xdr data which the client receives from the server as the value of the "acl" attribute.  It is up to userspace to do xdr decoding and encoding.
The data in the system.nfs4_acl attribute consists of the raw xdr data which the client receives from the server as the value of the "acl" attribute.  It is up to userspace to do xdr decoding and encoding.

Revision as of 21:52, 23 August 2005

The NFSv4 protocol includes integrated support for ACLs which appear to be similar to those used by Windows. These are different from the ACLs supported by earlier NFS versions, which are based on POSIX draft ACLs and which use a separate rpc program (instead of being a part of the NFS protocol itself).

Useful references:

  • rfc3530 (especially section 5.11)]
  • POSIX draft ACLs: POSIX ACLs aren't really POSIX--they were never accepted--but some variation of them is implemented on many operating systems, including Linux.
  • The Linux man pages, specifically, acl(5), setfacl(1), getfacl(1), and setxattr(2).
  • The POSIX<->NFSv4 mapping draft, which explains how we map between POSIX and NFSv4 ACLs.
  • The CITI NFSv4 project page, which has links to modified linux acl utilities with preliminary NFSv4 support

Basic design of the linux implementation:

None of the filesystems which the linux server exports support NFSv4 ACLs. However, many of them do support POSIX ACLs. So we map NFSv4 ACLs to POSIX ACLs and store POSIX ACLs in the filesystem. The mapping is imperfect, and prevents the server from accepting the full range of NFSv4 ACLs. We could instead store NFSv4 ACLs somewhere else--say in a separate extended attribute used only by the NFSv4 server. However, this would prevent our ACLs from being enforced against local users of the same filesystem. The code to perform this mapping on the server side is in the kernel, in fs/nfsd/nfs4acl.c.

The client also maps between NFSv4 and POSIX ACLs on the client, to allow it to support existing POSIX ACL interfaces. However it does this mapping in userspace; the kernel deals only in NFSv4 ACLs, which it exposes through a special extended attribute ("system.nfs4_acl"). Applications that use the POSIX ACL interfaces need to use a version of libacl that has been modified to do POSIX<->NFSv4 ACL mapping. But since userspace also has full access to the raw NFSv4 ACL, we can also provide utilities that get and set NFSv4 ACLs directly, without the need for mapping.

The data in the system.nfs4_acl attribute consists of the raw xdr data which the client receives from the server as the value of the "acl" attribute. It is up to userspace to do xdr decoding and encoding.

Personal tools