NFS V4 ACL Syntax
An NFS V4 ACL consists of a list of ACL entries. Where traditional ACLs can display one entry per line, the GPFS™ representation of NFS V4 ACL entries are three lines each, due to the increased number of available permissions beyond the traditional rwxc.
- The first part identifies the user or group.
- The second part displays a rwxc translation of the permissions that appear on the subsequent two lines.
- The third part is the ACL type. NFS V4 provides both an allow and deny type.
- allow
- Means to allow (or permit) those permissions that have been selected with an 'X'.
- deny
- Means to not allow (or deny) those permissions that have been selected with an 'X'.
- The fourth and final part is a list of flags indicating inheritance.
Valid flag values are:
- DirInherit
- Indicates that the ACL entry should be included in the initial ACL for subdirectories created in this directory (as well as the current directory).
- FileInherit
- Indicates that the ACL entry should be included in the initial ACL for files created in this directory.
- Inherited
- Indicates that the current ACL entry was derived from inherit entries in an NFS v4 ACL of the parent directory.
- InheritOnly
- Indicates that the current ACL entry should not apply to the directory, but should be included in the initial ACL for objects created in this directory.
- NoPropagateInherit
- Indicates that the ACL entry should be included in the initial ACL for subdirectories created in this directory but not further propagated to subdirectories created below that level.
As in traditional ACLs, users and groups are identified by specifying the type and name. For example, group:staff or user:bin. NFS V4 provides for a set of special names that are not associated with a specific local UID or GID. These special names are identified with the keyword special followed by the NFS V4 name. These names are recognized by the fact that they end with the character '@'. For example, special:owner@ refers to the owner of the file, special:group@ the owning group, and special:everyone@ applies to all users.
The next two lines provide a list of the available access permissions that may be allowed or denied, based on the ACL type specified on the first line. A permission is selected using an 'X'. Permissions that are not specified by the entry should be left marked with '-' (minus sign).
- An ACL entry that explicitly allows READ, EXECUTE and READ_ATTR to
the staff group on a file is similar to
this:
group:staff:r-x-:allow (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (-)SYNCHRONIZE (-)READ_ACL (X)READ_ATTR (-)READ_NAMED (-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED - A Directory ACL is similar to this. It may include inherit ACL
entries that do not apply to the directory itself, but instead become
the initial ACL for any objects created within the directory.
special:group@:----:deny:DirInherit:InheritOnly (X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (-)SYNCHRONIZE (-)READ_ACL (X)READ_ATTR (-)READ_NAMED (-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED - A complete NFS V4 ACL is similar to this:
#NFSv4 ACL #owner:smithj #group:staff special:owner@:rwxc:allow:FileInherit (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (-)READ_NAMED (X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (-)WRITE_NAMED special:owner@:rwxc:allow:DirInherit:InheritOnly (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (-)READ_NAMED (X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED user:smithj:rwxc:allow (X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (-)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (-)READ_NAMED (X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED