NSF v4 Access Control Lists and contents policy

Edit online

An NFS v4 Access Control List (ACL) contains the Type, Mask, and Flags fields.

The following is a description of these fields:

  • The Type field contains one of the following values:
    • ALLOW – Grants the subject, specified in the Who field, the permission(s) specified in the Mask field.
    • DENY – Denies the subject, specified in the Who field, the permission(s) specified in the Mask field.
  • The Mask field contains one or more of the following fine grained permission values:
    • READ_DATA / LIST_DIRECTORY – Read the data from a non-directory object or list the objects in a directory.
    • WRITE_DATA / ADD_FILE – Write data into a non-directory object or add a non-directory object to a directory.
    • APPEND_DATA / ADD_SUBDIRECTORY – Append data into a non-directory object or add a subdirectory to a directory.
    • READ_NAMED_ATTRS – Read the named attributes of an object.
    • WRITE_NAMED_ATTRS – Write the named attributes of an object.
    • EXECUTE – Execute a file or traverse/search a directory.
    • DELETE_CHILD – Delete a file or directory within a directory.
    • READ_ATTRIBUTES – Read the basic (non-ACL) attributes of a file.
    • WRITE_ATTRIBUTES – Change the times associated with a file or directory.
    • DELETE – Delete a file or directory.
    • READ_ACL – Read the ACL.
    • WRITE_ACL – Write the ACL.
    • WRITE_OWNER – Change the owner and group.
    • SYNCHRONIZE – Synchronize access (exists for compatibility with other NFS v4 clients, but has no implemented function).
  • Flags field – This field defines the inheritance capabilities of directory ACLs and indicates whether the Who field contains a group or not. This field contains zero or more of the following flags:
    • FILE_INHERIT – Specifies that, in this directory, newly created non-directory objects inherit this entry.
    • DIRECTORY_INHERIT – Specifies that, in this directory, newly created subdirectories inherit this entry.
    • NO_PROPAGATE_INHERIT – Specifies that, in this directory, newly created subdirectories inherit this entry, but these subdirectories do not pass this entry to their newly created subdirectories.
    • INHERIT_ONLY – Specifies that this entry does not apply to this directory, only to the newly created objects that inherit this entry.
    • IDENTIFIER_GROUP – Specifies that the Who field represents a group; otherwise, the Who field represents a user or a special Who value.
  • Who field – This field contains one of the following values:
    • User – Specifies the user to whom this entry applies.
    • Group – Specifies the group to which this entry applies.
    • Special – This attribute can be one of the following values:
      • OWNER@ – Specifies that this entry applies to the owner of the object.
      • GROUP@ – Specifies that this entry applies to the owning group of the object.
      • EVERYONE@ – Specifies that this entry applies to all users of the system including the owner and group.
If the ACL is empty, only a subject with an effective UID of 0 can access the object. The owner of an object implicitly has the following mask values regardless of what the ACL might or might not contain:
  • READ_ACL
  • WRITE_ACL
  • READ_ATTRIBUTES
  • WRITE_ATTRIBUTES

The APPEND_DATA value is implemented as WRITE_DATA . Effectively, there's no functional distinction between the WRITE_DATA value and the APPEND_DATA value. Both values must be set or unset in unison.

Object ownership can be modified through the use of the WRITE_OWNER value. When the owner or group is changed, the setuid bit is turned off. The inheritance flags only have meaning in a directory's ACL and only apply to objects that are created in the directory after the inheritance flags have been set (for example, existing objects are not affected by inheritance changes to the parent directory's ACL). The entries in an NFS v4 ACL are order dependent. To determine if the requested access is allowed, each entry is processed in order. Only entries that have the following values are considered:
  • A Who field that matches the effective UID
  • A user that is specified in the entry or effective GID
  • A group that is specified in the entry of the subject
Each entry is processed until all of the bits of the requester's access have been ALLOWED. After an access type has been ALLOWED by an entry, it is no longer considered in the processing of later entries. If a DENY entry is encountered where the requester's access for that mask value is necessary and undetermined, the request is denied. If the evaluation reaches the end of the ACL, the request is denied.

The maximum supported ACL size is 64 KB. Each entry in an ACL is of variable length and 64 KB is the only limit on an entry.