This topic describes the features of NFSv4 access control lists (ACLs) and POSIX ACLs.

Note

The NFS ACL feature is available only for NFS file systems in the following regions: China (Zhangjiakou-Beijing Winter Olympics), China (Beijing), China (Hohhot), China (Hangzhou), China (Shanghai), China (Chengdu), China (Hong Kong), Australia (Sydney), Indonesia (Jakarta), US (Silicon Valley), US (Virginia), Germany (Frankfurt), UK (London), and India (Mumbai). If the region where your file system resides does not support the NFS ACL feature, submit a ticket.

Features of Apsara File Storage NAS NFSv4 ACLs

  • Only access control entries (ACEs) of the allow type are supported. The following types of ACEs are not supported: deny, audit, and alarm.

    Deny ACEs increase the complexity of configuring permissions. In most cases, complexity leads to confusion and increases potential security risks. As agreed by the industry, we recommend that you avoid using deny ACEs. For more information about why deny ACEs are not recommended, see FAQ.

    Audit and alarm ACEs are not applicable to Apsara File Storage NAS NFS file systems. Instead, you can audit file systems and configure alerts based on auditing results in the Apsara File Storage NAS console.

  • If no ACL is specified for a file or a directory, the default ACL that corresponds to the predefined file mode creation mask is applied.
    touch file
    [root@vbox test]# ls -l file
    -rw-r--r--. 1 root root 0 May  6 14:27 file
    [root@vbox test]# nfs4_getfacl file
    # file: file
    A::OWNER@:rwatTnNcCy
    A::GROUP@:rtncy
    A::EVERYONE@:rtncy
  • An ACL is an ordered list that contains and deduplicates ACEs. This scheme ensures that permissions defined in an ACL are clear and informative.
    If you apply a new ACE and an existing ACE to the same object and the existing ACE is inherited from the parent object, the permissions of the new ACE override the permissions of the existing ACE. For example:
    • In an ACL that contains an ordered list of ACEs, ACEs that include the following principals are queued in sequence and take precedence over other ACEs: OWNER@, GROUP@, and EVERYONE@.
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTnNcCy
      A::GROUP@:rtncy
      A::EVERYONE@:rtncy
      A::1001:rwaxtTNcCy
    • Add an ACE of the read and write permissions to the following ACL for a user principal named 1009. The ACE is placed after the ACE that is defined for a user principal named 1001 based on the predefined order.
      [root@vbox test]# nfs4_setfacl -a A::1009:X file
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:tcy
      A::1001:rwaxtTNcCy
      A::1009:xtcy
    • Add a new ACE that includes the execute permission to the ACL. The system automatically merges the execute permission into the existing ACE for the 1009 user principal.
      [root@vbox test]# nfs4_setfacl -a A::1009:W file
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:tcy
      A::1001:rwaxtTNcCy
      A::1009:waxtTncCy
    • When you add the f and d inheritance flags to an ACE that includes a user principal named 1009, the system splits the ACE into two ACEs. One ACE has an extra inheritance flag named i specified, which indicates an inherit-only ACE. The other ACE only applies to the file object without any inheritance flag. If the inheritance type of an existing ACE matches the type for one of the two ACEs, the system combines the existing ACE with the ACE from the two ACEs. The two matching ACEs are converted into one ACE.
      [root@vbox test]# nfs4_setfacl -a A:fd:1009:R file
      [root@vbox test]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:tcy
      A::1001:rwaxtTNcCy
      A::1009:rwaxtTNcCy
      A:fdi:1009:r
  • All ACEs can be inherited.
    1. For example, the OWNER@ principal has the write access, the GROUP@ principal has the read access, and the EVERYONE@ has no access to the dir directory.
      [root@vbox nfs]# nfs4_getfacl dir
      # file: dir
      A::OWNER@:rwaDxtTnNcCy
      A::GROUP@:rxtcy
      A::EVERYONE@:tncy
    2. Add an ACE that grants a user principal named 1000 the read, write, and execute access to the dir directory. The f and d inheritance flags are also specified for the ACE.
      [root@vbox nfs]# nfs4_setfacl -a A:fd:1000:rwx dir
      [root@vbox nfs]# nfs4_getfacl dir
      # file: dir
      A::OWNER@:rwaDxtTcCy
      A::GROUP@:rxtcy
      A::EVERYONE@:tcy
      A::1000:rwx
      A:fdi:1000:rwx
    3. When you create a file or subdirectory in the dir directory, the file or the subdirectory automatically inherits all ACEs from the dir directory.
      [root@vbox nfs]# touch dir/file
      [root@vbox nfs]# nfs4_getfacl dir/file
      # file: dir/file
      A::OWNER@:rwatTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:rwatcy
      A::1000:rwx
      [root@vbox nfs]# mkdir dir/subdir
      [root@vbox nfs]# nfs4_getfacl dir/subdir
      # file: dir/subdir
      A::OWNER@:rwaDxtTcCy
      A::GROUP@:rwaDxtcy
      A::EVERYONE@:rwaDxtcy
      A:fdi:1000:rwx
    Note
    • We recommend that you grant the least privileges to the EVERYONE@ principal. Before you perform the following steps, we recommend that you run the umask 777 command. This command ensures that no access to a file or directory is granted when the file or directory is created. For more information, see Why doesn't umask change execute permissions on files? [duplicate].
    • When Linux calls functions to create files or directory, the predefined file mode creation mask is used as a request parameter. You can obtain the final ACL for a child object from the overlap of the inherited ACL (parent to child) and the file mode creation mask, as specified in the RFC7530 standard. When you modify the group bits of a file mode creation mask based on the standard, permissions included in an ACL for each group must be less than or equal to permissions defined in group bits. However, this scheme results in an invalid inheritance for groups. For example, you create a file and the file attempts to inherit A:RWX from a parent object. However, the predefined file mode creation mask sets the group bits to R. The final permission for the file becomes A:R. In actual practice, we recommend that you only modify file mode creation masks for ACLs that include the following principals: OWNER@, GROUP@, and EVERYONE@. This prevents against potential issues and ensures that semantics are clear. To remove permissions for a group, you only need to remove the ACE that relates to the group.
  • You need to maintain mappings between usernames or group names and user IDs (UIDs) or group IDs (GIDs) across multiple independent instances.

    Apsara File Storage NAS NFS adopts IP security groups rather than usernames to authenticate users. When you configure NFSv4 ACLs, UIDs or GIDs that are included in ACEs are stored in Linux. When you print an ACL for an object in a shell, Linux automatically loads the /etc/passwd file and converts UIDs or GIDs into usernames or group names. You need to maintain mappings between usernames or group names and UIDs or GIDs across multiple instances. You must ensure a username or group name is mapped to its UID or GID.

  • NFSv4 ACLs can be printed by using extended attributes.
    [root@vbox nfs]# getfattr -n system.nfs4_acl file
    # file: file
    system.nfs4_acl=0sAAAABgAAAAAAAAAAABYBhwAAAAZPV05FUkAAAAAAAAAAAAAAABIAhwAAAAZHUk9VUEAAAAAAAAAAAAAAABIAhwAAAAlFVkVSWU9ORUAAAAAAAAAAAAAAAAAAAAEAAAAEMTAwMAAAAAAAAAALAAAAAwAAAAQxMDAwAAAAAAAAAEAAFgGQAAAABTEwMDAxAAAA
  • Tools such as cp are supported for migrating NFSv4 ACLs.

    Apsara File Storage NAS supports migrating NFSv4 ACLs by using the cp, tar, and rsync tools. For more information, see How to preserve NFS v4 ACLs via extended attributes when copying file.

    The following cp --preserve=xattr file1 file2 command makes a copy of the file1 file as the file2 file while making a copy of the ACL of the file1 file for the file2 file. The cp -ar dir1 dir2 command makes a copy of the dir1 directory as the dir2 directory while making a copy of the ACL of the dir1 directory for the dir2 directory.
    Note You may fail to migrate NFSv4 ACLs if the version of the rsync tool is earlier than 3.1.2.
    [root@vbox nfs]# nfs4_getfacl file1
    # file: file1
    A::OWNER@:rwatTcCy
    A::GROUP@:rwatcy
    A::EVERYONE@:rwatcy
    A::1000:rtncy
    [root@vbox nfs]# cp --preserve=xattr file1 file2
    [root@vbox nfs]# nfs4_getfacl file2
    # file: file2
    A::OWNER@:rwatTcCy
    A::GROUP@:rwatcy
    A::EVERYONE@:rwatcy
    A::1000:rtncy
    [root@vbox nfs]# cp -ar dir1 dir2
  • Interoperation between NFSv4 ACLs and file mode creation masks is supported. The modification for the ACL of an object may change the file mode creation mask of the object. The modification for the file mode creation mask of an object may change the ACL of the object.
    For example, the file mode creation mask of the file object is 0666.
    [root@vbox nfs]# ls -l file
    -rw-rw-rw-. 1 root root 0 May  3  2019 file
    [root@vbox nfs]# nfs4_getfacl file
    # file: file
    A::OWNER@:rwatTcCy
    A::GROUP@:rwatcy
    A::EVERYONE@:rwatcy
    • If you add the execute permission to the file mode creation mask by modifying the owner bits, the execute permission is also added to the ACE that includes the OWNER@ principal.
      [root@vbox nfs]# chmod u+x file
      [root@vbox nfs]# ls -l file
      -rwxrw-rw-. 1 root root 0 May  3  2019 file
      [root@vbox nfs]# nfs4_getfacl file
      # file: file
      A::OWNER@:rwaxtTcCy
      A::GROUP@:rwatcy
      A::EVERYONE@:rwatcy
    • If you add the execute permission to an ACE that includes the GROUP@ principal, the execute permission is also added to the related file mode creation mask.
      [root@vbox nfs]# nfs4_setfacl -a A::GROUP@:x file
      [root@vbox nfs]# ls -l file
      -rwxrwxrw-. 1 root root 0 May  3  2019 file
    Note
    • In the interaction between ACLs and file mode creation masks, the EVERYONE@ principal is equal to the others class. When you modify the others class, the change also applies to the EVERYONE@ principal. This operation causes a slight impact on the semantics of permissions. For example, the current file mode creation mask is 177. After you run the chmod o+r command, all users that include the file owner and group members have the read permission. This occurs because the read permission is added to the related ACE that includes the EVERYONE@ principal. If no change is applied to the default file mode creation mask, the owner and group classes still have no read permission after you run the chmod o+r command.
    • If no change is applied to NFSv4 ACLs, the others class of the file mode creation mask keeps the same semantics. If an NFSv4 ACL is changed, the semantics of the others class changes to the semantics of the EVERYONE@ principal and keeps the semantics. We recommend that you do not use file mode creation masks after using NFSv4 ACLs.
  • Interactions between NFSv4 ACLs and POSIX ACLs are supported.

    You can mount file systems that have NFSv4 ACLs applied by using the NFSv3 protocol. These NFSv4 ACLs will then be converted into POSIX ACLs. You can also mount file systems that have POSIX ACLs applied by using the NFSv4 protocol. These POSIX ACLs will then be converted into NFSv4 ACLs.

    Note The semantics of POSIX ACLs are different from the semantics of NFSv4 ACLs. For example, the inheritance rules that apply to POSIX ACLs do not differentiate files and directories. NFSv4 ACLs have more diverse permissions than POSIX ACLs, which have only read, write, and execute permissions. We recommend that you use either NFSv4 ACLs or POSIX ACLs to prevent against potential issues.

    For example, you configure an NFSv4 ACL for the dir0 directory. The permissions are listed as follows.

    [root@vbox test] sudo nfs4_getfacl dir0
    A::OWNER@:tTnNcCy
    A::GROUP@:tncy
    A::EVERYONE@:tncy
    A:fdi:EVERYONE@:tncy
    A:fdi:OWNER@:tTnNcCy
    A:fdi:GROUP@:tncy
    A:g:19064:rxtncy
    A:g:19065:rwaDxtTnNcCy
    A:fdig:19064:rxtncy
    A:fdig:19065:rwaDxtTnNcCy

    You configure a POSIX ACL for the dir0 directory. The permissions are listed as follows.

    [root@vbox test] sudo getfacl dir0
    user::---
    group::---
    group:players:r-x
    group:adminis:rwx
    mask::rwx
    other::---
    default:user::---
    default:group::---
    default:group:players:r-x
    default:group:adminis:rwx
    default:mask::rwx
    default:other::---

    For example, you configure an NFSv4 ACL for the dir0/file file. The permissions are listed as follows.

    [root@vbox test] sudo nfs4_getfacl dir0/file
    A::OWNER@:tTnNcCy
    A::GROUP@:tncy
    A::EVERYONE@:tncy
    A:g:19064:rxtncy
    A:g:19065:rwaxtTnNcCy

    For example, you configure a POSIX ACL for the dir0/file file. The permissions are listed as follows.

    [root@vbox test] sudo getfacl dir0/file
    user::---
    group::---
    group:players:r-x
    group:adminis:rwx
    mask::rwx
    other::---
  • The number of NFSv4 ACLs is limited.
    Apsara File Storage NAS supports a maximum of 100,000 ACLs that are different from one another in each file system by default. Each ACL contains a maximum of 500 ACEs.
    Note We recommend that you do not abuse ACLs and ACEs. This reduces the time and resources consumed for verifying permissions.

Features of Apsara File Storage NAS POSIX ACLs

  • Permissions that are specified for the other class apply to all.

    Everyone includes the owner, group, and users that are related to each ACE. The other class is equal to the EVERYONE@ principal of an NFSv4 ACL.

    Note We recommend that you grant the least permissions to the other class for all cases.

    For example, the following ACL is configured for the myfile file. Although the ACE contains a user named alice who does not have the write permission, the write permission propagates to the ACE because the permission is specified for the other class.

    [root@vbox 3]# getfacl myfile
    # file: myfile
    # owner: root
    # group: root
    user::rw-
    user:alice:r--
    group::r--
    mask::r--
    other::rw-
  • Permissions that are configured by ACLs will not be changed after you run the chmod command.
    Note We recommend that you avoid modifying the file mode creation mask of a file that has a POSIX ACL applied. You can configure permissions for the file by modifying the POSIX ACL.
    1. For example, an ACE that grants the players group the read and write access to the myfile file.
      [root@vbox 3]# getfacl myfile
      # file: myfile
      # owner: root
      # group: root
      user::rw-
      user:player:rw-
      group::rw-
      group:players:rw-
      mask::rw-
      other::---
    2. The chmod g-w myfile or chmod u-w myfile command does not change the permissions that are granted to the player user and the players group, which is different from the POSIX ACL standard. However, this ensures that permissions that are granted by POSIX ACLs to non-reserved users are the same after you modify permissions by using file mode creation masks. The non-reserved users include all users except for the users of the owner, group, and other classes.
      [root@vbox 3]# getfacl myfile
      # file: myfile
      # owner: root
      # group: root
      user::r--
      user:player:rw-
      group::r--
      group:players:rw-
      mask::rw-
      other::---
  • If the execute permission is not granted to the group and other classes of an ACL, the ACL has no execute permission.

    The rule is predefined in Linux. The execute action is allowed by the backend of Apsara File Storage NAS. However, to make the execute permission in the ACL effective, you must grant the execute permission to the group or other class.

    For example, if the group and other classes do not have the execute access to the myfile file, the player user cannot execute the file.

    [root@vbox 3]# getfacl myfile
    # file: myfile
    # owner: root
    # group: root
    user::rw-
    user:player:r-x
    group::r--
    mask::r-x
    other::r--
    If you grant the execute permission to the group class, the execute permission also propagates to the player user.
    [root@vbox 3]# getfacl myfile
    # file: myfile
    # owner: root
    # group: root
    user::rw-
    user:player:r-x
    group::r-x
    mask::r-x
    other::r--
  • If you configure inheritable NFSv4 ACLs for directories, these settings may not conform to the POSIX ACL standard when these directories reside in NFSv3 file systems.

    Inheritance rules that apply to files are different from those that apply to directories in NFSv4 ACLs. The same inheritance rules apply to both files and directories in POSIX ACLs.

    Note We recommend that you apply either NFS4 ACLs or POSIX ACLs to an NFS file system to prevent against potential issues.
  • File mode creation masks cannot be modified.

    The file mode creation mask of a POSIX ACL is yielded by the combination and interaction of permissions from all users and groups. The mask has no practical meaning and cannot be changed.

  • You need to maintain mappings between usernames or group names and user IDs (UIDs) or group IDs (GIDs) across multiple instances.

    Apsara File Storage NAS NFS adopts IP security groups rather than usernames to authenticate users. When you configure POSIX ACLs, UIDs or GIDs that are included in ACEs are stored in Linux. When you print an ACL for an object in a shell, Linux automatically loads the /etc/passwd file and converts UIDs or GIDs into actual usernames or group names. You need to maintain mappings between usernames or group names and UIDs or GIDs across multiple instances. You must ensure a username or group name is mapped to its related UID or GID.

  • POSIX ACLs can be printed by using extended attributes.
    [root@vbox nfs]# getfattr -n system.posix_acl_access file
    # file: file
    system.posix_acl_access=0sAgAAAAEAAAD/////AgAFACAEAAAEAAAA/////xAABQD/////IAABAP////8=
  • POSIX ACLs can be migrated by using tools such as cp.

    Apsara File Storage NAS supports migrating POSIX ACLs by using the cp, tar, and rsync tools. For more information, see How to preserve NFS v4 ACLs via extended attributes when copying file.

    The following cp --preserve=xattr file1 file2 command makes a copy of the file1 file as the file2 file while making a copy of the ACL of the file1 file for the file2 file. The cp -ar dir1 dir2 command makes a copy of the dir1 directory as the dir2 directory while making a copy of the ACL of the dir1 directory for the dir2 directory.
    Note You may fail to migrate POSIX ACLs if the version of the rsync tool is earlier than 3.1.2.
    [root@vbox nfs]# getfacl file1
    user::---
    user:player:r-x
    group::---
    mask::r-x
    other::--x
    [root@vbox nfs]# cp --preserve=xattr file1 file2
    [root@vbox nfs]# getfacl file2
    # file: file2
    user::---
    user:player:r-x
    group::---
    mask::r-x
    other::--x
    [root@vbox nfs]# cp -ar dir1 dir2
  • The number of POSIX ACLs is limited.
    Apsara File Storage NAS supports a maximum of 100,000 ACLs that are different from one another in each file system by default. Each ACL contains a maximum of 500 ACEs.
    Note We recommend that you do not abuse ACLs and ACEs. This reduces the time and resources consumed for verifying permissions.

FAQ

Why are deny ACEs not supported?
  • The position of an ACE that resides in an ACL is important.

    The sequence for ACEs that reside in an NFSv4 ACL is random. A deny ACE may be placed in any position of an NFSv4 ACL. For example, an ACL contains two ACEs: A::Alice:r and D::Alice:r. The position of the ACEs determines whether the Alice user has the write permission.

    Note When you configure an ACL, you must consider the position of each ACE.
  • The number of ACEs in an ACL experience a sharp increase.

    You may have difficulties to combine and deduplicate ACEs in an ACL because the sequencing for ACEs is not mandatory. The number of ACEs may increase up to tens or hundreds over a long period of time. To manage the final permissions that are produced by these ACEs, you need to check each ACE. The process to check is strenuous and time-consuming.

  • The interactions between file mode creation masks and ACLs become more complex after deny ACEs are applied because deny features do not exist in file mode creation masks.
    • If deny ACEs are available, you may need to add several ACEs to an ACL when the file mode creation mask is changed. For example, if you change the file mode creation mask to -rw-rw-rw, you need to add the following ACEs to an ACL. You must add the ACEs in sequence at the beginning of the ACL.
      A::OWNER@:rw
      D::OWNER@:x
      A::GROUP@:rw
      D::GROUP@:x
      A::EVERYONE@:rw
      D::EVERYONE@:x
    • If deny ACEs are unavailable, you can sequence and deduplicate ACEs. You do not need to differentiate the EVERYONE@ principal and the other class. You can modify an ACL with ease when the file mode creation mask is changed. In such cases, you only need to find ACEs that contain the OWNER@, GROUP@, and EVERYONE@ principals and modify these ACEs as follows.
      A::OWNER@:rw
      A::GROUP@:rw
      A::EVERYONE@:rw
  • Conversions between NFSv4 ACLs and POSIX ACLs are not supported in some cases.

    POSIX ACLs do not support deny ACEs. If one or more deny ACEs are included in an NFSv4 ACL, you cannot convert the ACL into a POSIX ACL.