ACLs

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
-
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).
+
= Introduction to NFSv4 ACLs =
 +
 
 +
Some NFSv2 and v3 implementations support ACLs based on POSIX draft ACLs which depend on a searate rpc program (instead of being part of the NFS protocol itself).
 +
 
 +
The NFSv4 protocol includes integrated support for ACLs which are similar to those used by Windows.  NFSv4 ACLs are richer than POSIX draft ACLs--any POSIX ACL can be represented by an NFSv4 ACL with almost the same semantics, whereas the reverse is not true.
Useful references:
Useful references:
Line 10: Line 14:
* NFS Version 4 ACLs: http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt
* NFS Version 4 ACLs: http://www.ietf.org/internet-drafts/draft-falkner-nfsv4-acls-00.txt
-
Basic design of the linux implementation:
+
= Design of the linux NFSv4 ACL implementation =
 +
 
 +
== Server ==
 +
 
 +
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.
-
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.
+
== Client ==
-
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 client can also map between NFSv4 and POSIX ACLs, 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.
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 19:50, 10 March 2006

Contents

Introduction to NFSv4 ACLs

Some NFSv2 and v3 implementations support ACLs based on POSIX draft ACLs which depend on a searate rpc program (instead of being part of the NFS protocol itself).

The NFSv4 protocol includes integrated support for ACLs which are similar to those used by Windows. NFSv4 ACLs are richer than POSIX draft ACLs--any POSIX ACL can be represented by an NFSv4 ACL with almost the same semantics, whereas the reverse is not true.

Useful references:

Design of the linux NFSv4 ACL implementation

Server

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.

Client

The client can also map between NFSv4 and POSIX ACLs, 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