nfs4_acl - Man Page

An ACL is a list of permissions associated with a file or directory and  consists of one or more Access Control Entries (ACEs).  NFSv4  ACLs provide finer granularity than typical POSIX read/write/execute permissions and are similar to CIFS ACLs.  

A sample NFSv4 file ACL might look like the following (see the Acl Format section for detailed information):

A::OWNER@:rwatTnNcCy
A::alice@nfsdomain.org:rxtncy
A::bob@nfsdomain.org:rwadtTnNcCy
A:g:GROUP@:rtncy
D:g:GROUP@:waxTC
A::EVERYONE@:rtncy
D::EVERYONE@:waxTC

Some observations:

• In the example output above, the user `alice@nfsdomain.org' has the equivalent of "read" and "execute" permissions, `bob@nfsdomain.org' has "read" and  "write", and both `GROUP@' and `EVERYONE@' have "read".
• NFSv4 ACLs are "default-deny"; that is, if a permission is not explicitly  granted by an Allow ACE, it is denied.  Because of this, the two Deny ACEs  above are superfluous and could be excluded by the server.  See the A Warning About Deny Aces section for more information.
• NFSv4 servers may return an ACL slightly different than one you set.  For  example, a server that always allows reading the attributes of a file may  silently turn on the read-attributes permission, and a server that does not support separate write-data and append-data permissions, e.g., may choose to turn off both if you set only one.  In extreme  cases the server may also reorder or combine ACEs.  As a general rule,  however, servers will attempt to ensure that the ACLs they return are no  more permissive than the ones you set.

An NFSv4 ACL is written as an acl_spec, which is a comma- or tab-delimited string consisting of one or more ace_specs. A single NFSv4 ACE is written as an ace_spec, which is a colon-delimited, 4-field string in the following format:

Inheritance flags can be divided into two categories:  "primary" (file-inherit and directory-inherit); and  "secondary" (no-propagate-inherit and inherit-only),  which are significant only insofar as they affect the two "primary" flags.

The no-propagate-inherit and inherit-only flags can be tricky to remember: the former determines whether or not a new child directory's inherited ACE is itself heritable by a grandchild subdirectory; the latter determines whether or not a heritable ACE affects the parent directory itself (in addition to being heritable).  They can be used in-tandem.

When a subdirectory inherits an ACE from its parent directory's ACL, this can happen in one of two different ways, depending on the server implementation:

• In the simple case, that exact same ACE is set in the subdirectory's ACL.
• In the other case, two different ACEs will instead be set in the subdirectory's ACL: one with all inheritance flags removed, and one with the inherit-only flag added.  The former is the "effective" inherited ACE (used in the subdirectory's own permissions checks); the latter is the "heritable" inherited ACE (when the  subdirectory has directories created within it, they inherit it).  This approach  makes it easier to modify access rights to the subdirectory itself without  modifying its heritable ACEs. The Linux kernel server uses this approach.

Deny ACEs should be avoided whenever possible.  Although they are a valid part of NFSv4 ACLs, Deny ACEs can be confusing and complicated.  This stems  primarily from the fact that, unlike POSIX ACLs and CIFS ACLs, the ordering of ACEs within NFSv4 ACLs affects how they are evaluated.

First, it is important to note that (despite some unfortunate ambiguity in RFC3530) NFSv4 ACLs are "default-deny" in practice.  That is, if a permission is not explicitly granted, it is denied.  

In general, when a principal is attempting to perform an action over NFSv4 which requires one or more permissions, an access check is performed. The NFSv4 ACL (assuming one is present) is evaluated ACE-by-ACE until every one of those permissions has been addressed, or until the end of the ACL is reached.  If every requisite permission was granted by Allow ACEs and was not forbidden by Deny ACEs (see next paragraph),  the action is allowed to proceed.  Otherwise, the action is forbidden.

Note that each requisite permission is only addressed once -- that is, after a permission has been explicitly Allowed or Denied once during an access check,  any subsequent ACEs in the ACL which affect that permission are no longer considered.  This often introduces problematic ordering issues when Deny ACEs are present.

Additionally, in some cases Group-Deny ACEs can be difficult (if not  impossible) to enforce, since a server might not know about all of a given principal's memberships in remote groups, e.g.

Because NFSv4 ACLs are "default-deny", the use of Deny ACEs can (and should)  be avoided entirely in most cases.  

Tools for viewing and manipulating NFSv4 ACLs, nfs4_getfacl and nfs4_setfacl, were written by people at CITI, the Center for Information Technology Integration (http://www.citi.umich.edu). This manpage was written by David Richter and J. Bruce Fields.

Please send bug reports, feature requests, and comments to <nfsv4@linux-nfs.org>.

nfs4_getfacl(1), nfs4_setfacl(1), RFC3530 (NFSv4.0), NFSv4.1 Minor Version Draft.

nfs4_getfacl(1), nfs4_setfacl(1).