nfs4_acl man page

nfs4_acl — NFSv4 Access Control Lists

Description

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:

Acl Format

An NFSv4 ACL is written as an acl_spec, which is a comma- or whitespace-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:

type:flags:principal:permissions

Ace Types

There are four types of ACEs, each represented by a single character.  An ACE must have exactly one type.

A

Allow - allow principal to perform actions requiring permissions.

D

Deny - prevent principal from performing actions requiring permissions.

U

Audit - log any attempted access by principal which requires permissions. Requires one or both of the successful-access and failed-access flags. System-dependent; not supported by all servers.

L

Alarm - generate a system alarm at any attempted access by principal which requires permissions. Requires one or both of the successful-access and failed-access flags. System-dependent; not supported by all servers.

Ace Flags

There are three kinds of ACE flags: group, inheritance, and administrative.  An Allow or Deny ACE may contain zero or more flags, while an Audit or Alarm ACE must contain at least one of the successful-access and failed-access flags.

Note that ACEs are inherited from the parent directory's ACL at the time a file or subdirectory is created.  Accordingly, inheritance flags can be used only in  ACEs in a directory's ACL (and are therefore stripped from inherited ACEs in a new file's ACL).  Please see the Inheritance Flags Commentary section for more information.

GROUP FLAG - can be used in any ACE
g

group - indicates that principal represents a group instead of a user.

INHERITANCE FLAGS - can be used in any directory ACE
d

directory-inherit - newly-created subdirectories will inherit the ACE.

f

file-inherit - newly-created files will inherit the ACE, minus its inheritance flags. Newly-created subdirectories will inherit the ACE; if directory-inherit is not also specified in the parent ACE, inherit-only will be added to the inherited ACE.

n

no-propagate-inherit - newly-created subdirectories will inherit the ACE, minus its inheritance flags.

i

inherit-only - the ACE is not considered in permissions checks, but it is heritable; however, the inherit-only flag is stripped from inherited ACEs.

ADMINISTRATIVE FLAGS - can be used in Audit and Alarm ACEs
S

successful-access - trigger an alarm/audit when principal is allowed to perform an action covered by permissions.

F

failed-access - trigger an alarm/audit when principal is prevented from performing an action covered by permissions.

Ace Principals

A principal is either a named user (e.g., `myuser@nfsdomain.org') or group  (provided the group flag is also set), or one of three special principals: `OWNER@', `GROUP@', and `EVERYONE@', which are, respectively, analogous  to the POSIX user/group/other distinctions used in, e.g., chmod(1).

Ace Permissions

There are a variety of different ACE permissions (13 for files, 14 for directories), each represented by a single character.   An ACE should have one or more of the following permissions specified:

r

read-data (files) / list-directory (directories)

w

write-data (files) / create-file (directories)

a

append-data (files) / create-subdirectory (directories)

x

execute (files) / change-directory (directories)

d

delete - delete the file/directory.  Some servers will allow a delete to occur  if either this permission is set in the file/directory or if the delete-child permission is set in its parent direcory.

D

delete-child - remove a file or subdirectory from within the given directory (directories only)

t

read-attributes - read the attributes of the file/directory.

T

write-attributes - write the attributes of the file/directory.

n

read-named-attributes - read the named attributes of the file/directory.

N

write-named-attributes - write the named attributes of the file/directory.

c

read-ACL - read the file/directory NFSv4 ACL.

C

write-ACL - write the file/directory NFSv4 ACL.

o

write-owner - change ownership of the file/directory.

y

synchronize - allow clients to use synchronous I/O with the server.

Inheritance Flags Commentary

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:

A Warning About Deny Aces

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.  

Authors

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.

Contact

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

See Also

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

Referenced By

nfs4_getfacl(1), nfs4_setfacl(1).

version 0.3.3, August 2008 Linux NFSv4 Access Control Lists