NFS4 Access Control List

Edit online

AIX® also supports the NFS4 Access Control List (ACL) type.

The NFS4 ACL type implements access control as specified in the Network File System (NFS) version 4 Protocol RFC 3530. The JFS2 file system allows a maximum size of 64KB for NFS4 ACLs.

Only NFS V4 client supports NFS V4 ACLs. Both, Cachefs and Proxy do not support NFS V4 ACLs.

Textual representation of NFS4 ACL

A textual NFS V4 ACL is a list of ACEs (Access Control Entries) each ACE per line. An ACE has four elements in the following format. 
IDENTITY   ACE_TYPE      ACE_MASK     ACE_FLAGS

where:
IDENTITY => Has format of 'IDENTITY_type:(IDENTITY_name or IDENTITY_ID or IDENTITY_who):'
         where:
         IDENTITY_type => One of the following Identity type:
                 u : user
                 g : group
                 s : special who string (IDENTITY_who must be a special who)
                         IDENTITY_name => user/group name
                         IDENTITY_ID   => user/group ID
                         IDENTITY_who  => special who string (e.g. OWNER@, GROUP@, EVERYONE@)
ACE_TYPE => One of the following ACE Type:
                a : allow
                d : deny
                l : alarm
                u : audit
ACE MASK => One or more of the following Mask value Key without separator:
                r : READ_DATA			or LIST_DIRECTORY
                w : WRITE_DATA      or ADD_FILE
                p : APPEND_DATA     or ADD_SUBDIRECTORY
                R : READ_NAMED_ATTRS
                W : WRITE_NAMED_ATTRS
                x : EXECUTE         or SEARCH_DIRECTORY
                D : DELETE_CHILD
                a : READ_ATTRIBUTES
                A : WRITE_ATTRIBUTES
                d : DELETE
                c : READ_ACL
                C : WRITE_ACL
                o : WRITE_OWNER
                s : SYNCHRONIZE
ACE_FLAGS (Optional) => One or more of the following Attribute Key without separater:
                fi : FILE_INHERIT
                di : DIRECTORY_INHERIT
                oi : INHERIT_ONLY
                ni : NO_PROPAGATE_INHERIT
                sf : SUCCESSFUL_ACCESS_ACE_FLAG
                ff : FAILED_ACCESS_ACE_FLAG
Note: Concerning the SYNCHRONIZE Ace_Mask value key, s, AIX does not take any action concerning this value key. The AIX operating system stores and preserves the s value key but this value key does not have any meaning to AIX.

When the WRITE_OWNER Ace_Mask is set to Ace_Type allow, users can change ownership of the file to themselves only.

Deleting a file depends on two ACEs, the DELETE entry of the object to be deleted and the DELETE_CHILD entry of its parent directory. The AIX operating system provides the user with two modes of behavior. In the secure mode, DELETE behaves similar to AIXC ACLs. In the compatibility mode, DELETE behaves like other major implementations of NFS4 ACLs. To turn on the compatibility mode, use the chdev command as follows:
chdev -l sys0 -a nfs4_acl_compat=compatible
You must reboot the system after running the chdev command before the configuration change will take place.

If you switch your system back and forth between the two modes, you need to be aware that NFS4 ACLs generated by the AIX operating system in secure mode might not be accepted by other platforms even if the system was changed back to compatibility mode.

Example:
        u:user1(aa@ibm.com):     a    rwp    fidi
        *s:(OWNER@):             d    x      dini          * This line is a comment
        g:staff(jj@jj.com):      a    rx
        s:(GROUP@):              a    rwpx   fioi
        u:2:                     d    r     di             * This line shows user bin (uid=2)
        g:7:                     a    ac    fi             * This line shows group security (gid=7)
        s:(EVERYONE@):           a    rca   ni

Binary format for NFS4 ACL

The NFS4 ACL binary format is defined in /usr/include/sys/acl.h and is implemented in the current AIX release.

NFS4 ACL example

The following example shows an NFS4 ACL applied on a directory (such as, j2eav2/d0):

s:(OWNER@):         a         rwpRWxDdo         difi         * 1st   ACE 
s:(OWNER@):         d         D                 difi         * 2nd  ACE 
s:(GROUP@):         d         x                 ni           * 3rd   ACE 
s:(GROUP@):         a         rx                difi         * 4th   ACE 
s:(EVERYONE@):      a         c                 difi         * 5th   ACE 
s:(EVERYONE@):      d         C                 difi         * 6th   ACE 
u:user1:            a         wp                oi           * 7th   ACE
g:grp1:             d         wp                             *  8th  ACE 
u:101:              a         C                              * 9th   ACE 
g:100:              d         c                              * 10th  ACE
The ACL entries are described as follows:
  • The first ACE indicates that the owner has the following privileges on /j2eav2/d0 and all its offspring created after this ACL is applied:
    • READ_DATA (= LIST_DIRECTORY)
    • WRITE_DATA (=ADD_FILE)
    • APPEND_DATA (= ADD_SUBDIRECTORY)
    • READ_NAMED_ATTR
    • WRITE_NAMED_ATTR
    • EXECUTE (=SEARCH_DIRECTORY)
    • DELETE_CHILD
    • DELETE
    • WRITE_OWNER
  • The second ACE indicates the owner is denied the privilege for DELETE_CHILD (deleting the files or subdirectories created under /j2eav2), but owner can still delete them because of the first ACE, which allows owner the privilege for DELETE_CHILD.
  • The third ACE indicates all members of the group for the object (/j2eav2/d0) are denied the privilege for EXECUTE (=SEARCH_DIRECTORY), but the owner is still allowed that privilege by the first ACE. This ACE can not be propagated to all of its offsprings because the NO_PROPAGATE_INHERIT flag is specified. This ACE is applied only to the directory /j2eav2/d0 and its immediate child files and subdirectories.
  • The fourth ACE indicates that every member of the group of the object (/j2eav2/d0) is allowed the privilege for READ_DATA (= LIST_DIRECTORY) and EXECUTE (=SEARCH_DIRECTORY) on /j2eav2/d0 and all its offsprings. However, because of third ACE group members (except the owner) are not allowed the privilege for EXECUTE (=SEARCH_DIRECTORY) on the /j2eav2/d0 directory and its immediate child files and subdirectories.
  • The fifth ACE indicates that everyone is allowed the privilege for READ_ACL on the /j2eav2/d0 directory and any offspring that are created after this ACL is applied.
  • The sixth ACE indicates that everyone is denied the privilege for WRITE_ACL on the /j2eav2/d0 directory and any offspring. The owner always has the privilege for WRITE_ACL on files and directories with NFS4 ACLs.
  • The seventh ACE indicates that user1 has the privilege for WRITE_DATA (=ADD_FILE) and APPEND_DATA (= ADD_SUBDIRECTORY) on all the offspring of the /j2eav2/d0 directory but not on the /j2eav2/d0 directory itself.
  • The eighth ACE indicates that all the members of grp1 are denied the privilege for WRITE_DATA (=ADD_FILE) and APPEND_DATA (= ADD_SUBDIRECTORY). This ACE does not apply to the owner even it belongs to grp1 because of the first ACE.
  • The ninth ACE indicates that the user with UID 101 has the privilege for WRITE_ACL, but no one, except the owner has the privilege for WRITE_ACL because of the sixth ACE.
  • The tenth ACE indicates that all the members of the group with GID 100 are denied for READ_ACL, but they will have this privilege because of the fifth ACE.