GPFS: Administration and Programming Reference - IRA Home

changed by using the mmputacl or mmeditacl command to assign a new ACL or by the mmdelacl
command (causing the permissions to revert to the mode which is in effect a POSIX ACL). At any point in
time, only a single ACL can be associated with a file. Access evaluation is done as required by the ACL
type associated with the file.
NFS V4 ACLs are represented in a completely different format than traditional ACLs. For detailed
information on NFS V4 and its ACLs, refer to the paper, NFS Version 4 Protocol and other information
found at: www.nfsv4.org.
In the case of NFS V4 ACLs, there is no concept of a default ACL. Instead, there is a single ACL and the
individual ACL entries can be flagged as being inherited (either by files, directories, both, or neither).
Consequently, specifying the -d flag on the mmputacl command for an NFS V4 ACL is an error.
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 line has several parts separated by colons (’:’).
v The first part identifies the user or group.
v The second part displays a rwxc translation of the permissions that appear on the subsequent two
lines.
v 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’.
v The fourth and final part is a list of flags indicating inheritance.
Valid flag values are:
FileInherit Indicates that the ACL entry should be included in the initial ACL for files created in this
directory.
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).
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.
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 in 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).
These are examples of NFS V4 ACLs.
1. 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 (-)MKDIR (-)SYNCHRONIZE (-)READ_ACL (X)READ_ATTR (-)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
Chapter 6. Managing GPFS access control lists and NFS export 49