ACLs

From Linux NFS

Revision as of 23:28, 2 November 2005 by 134.9.14.32 (Talk)
Jump to: navigation, search

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:

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