NFSv4 ACL and POSIX ACL features - File Storage NAS - Alibaba Cloud Documentation Center

This topic describes the features related to NFSv4 ACL and POSIX ACL.

NAS NFSv4 ACL features

Only the Allow ACE type is supported. Deny, Audit, and Alarm are not supported.
Deny ACE greatly increases the complexity of permission settings, which can confuse users and create security issues. The industry has reached a consensus that Deny ACE should be avoided as much as possible. For details about why Deny ACE is not supported, see FAQ.
Audit ACE and Alarm ACE do not take effect on Alibaba Cloud NAS NFS. If you need audit and alarm features, you can configure them in the Alibaba Cloud console.
Files or directories without ACL set will display a default ACL corresponding to the mode. The following is an example:
1. Run the touch file command to enter the file.
2. Run the ls -l file command to view the permissions of the file.
```
-rw-r--r--. 1 root root 0 May 6 14:27 file
```
3. Run the nfs4_getfacl file command to view the current ACL permissions of the file.
```
# file: file
A::OWNER@:rwatTnNcCy
A::GROUP@:rtncy
A::EVERYONE@:rtncy
```
ACEs are arranged in a specific order and deduplicated, making the ACL output clearer and easier to understand.
When a user adds or modifies an ACE, if the ACL already contains an ACE with a fully qualified inheritance type, the new ACE is merged with the Allow bits of the existing ACE. For example:
- During ordering, ACEs corresponding to owner, group, and everyone are always placed at the front.
  You can run the nfs4_getfacl file command to view the ACL permission ordering of the file.
```
# file: file
A::OWNER@:rwaxtTnNcCy
A::GROUP@:rtncy
A::EVERYONE@:rtncy
A::1001:rwaxtTNcCy
```
- A read/write permission ACE is added for user 1009, placed after user 1001 following the ordering.
  - Run the command
```
nfs4_setfacl -a A::1009:X file
nfs4_getfacl file
```
  - Example output
```
# file: file
A::OWNER@:rwaxtTcCy
A::GROUP@:rwatcy
A::EVERYONE@:tcy
A::1001:rwaxtTNcCy
A::1009:waxtTncCy
```
- An execute permission ACE is added for user 1009. The system automatically merges the new execute permission into the existing ACE for user 1009.
  - Run the command
```
nfs4_setfacl -a A::1009:W file
nfs4_getfacl file
```
  - Example output
```
# file: file
A::OWNER@:rwaxtTcCy
A::GROUP@:rwatcy
A::EVERYONE@:tcy
A::1001:rwaxtTNcCy
A::1009:waxtTncCy
```
- An fd inheritance ACE is added for user 1009. The system splits it into an ACE with only inheritance capability and an ACE that applies only to the current file, and then merges both ACEs with ACEs of the same inheritance type in the ACL.
  - Run the command
```
nfs4_setfacl -a A:fd:1009:R file
nfs4_getfacl file
```
  - Example output
```
# file: file
A::OWNER@:rwaxtTcCy
A::GROUP@:rwatcy
A::EVERYONE@:tcy
A::1001:rwaxtTNcCy
A::1009:rwaxtTNcCy
A:fdi:1009:r
```
All inheritance features are supported.
1. Assume that the current directory dir has permissions: owner can write, group can read, and everyone has no access.
  - Run the command
```
nfs4_getfacl dir
```
  - Example output
```
# file: dir
A::OWNER@:rwaDxtTnNcCy
A::GROUP@:rxtcy
A::EVERYONE@:tncy
```
2. Read/write permissions with inheritance enabled are added for user 1000.
  - Run the command
```
nfs4_setfacl -a A:fd:1000:rwx dir
nfs4_getfacl dir
```
  - Example output
```
# file: dir
A::OWNER@:rwaDxtTcCy
A::GROUP@:rxtcy
A::EVERYONE@:tcy
A::1000:rwx
A:fdi:1000:rwx
```
3. Files or directories created under directory dir automatically inherit the ACE.
  - Create a file under directory dir
    - Run the command
```
touch dir/file
nfs4_getfacl dir/file
```
    - Example output
```
# file: dir/file
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
A::1000:rwx
```
  - Create a directory under directory dir
    - Run the command
```
mkdir dir/subdir
nfs4_getfacl dir/subdir
```
    - Example output
```
# file: dir/subdir
A::OWNER@:rwaDxtTcCy
A::GROUP@:rwaDxtcy
A::EVERYONE@:rwaDxtcy
A:fdi:1000:rwx
```
Note
- It is recommended to keep EVERYONE permissions as small as possible. Before running the relevant code, run umask 777 first so that the mode passed in when creating files and directories becomes 000, which minimizes default permissions. For details, see Why doesn't umask change execute permissions on files?.
- Linux system calls for files and directories pass mode as a parameter by default. According to the RFC 7530 protocol standard, after the inherited ACL is applied, mode operations must be layered on top to modify the ACL. Per the protocol, if the group mode is modified, all group ACEs must have permissions less than or equal to the group mode permission. This can cause group inheritance to fail. For example: a child file was originally supposed to inherit Group A: RWX, but the default mode passed in is GROUPS: R, so the child file's Group A ACE becomes Group A: R. To avoid this issue, in practice, mode will not modify ACL for groups other than owner, group, and everyone, which makes the semantics simpler. To remove a group's permissions, you can directly delete the corresponding ACE.
The mapping of usernames to UIDs and GIDs across multiple machines must be maintained by yourself.
Currently, Alibaba Cloud NAS NFS authentication uses IP security groups and does not support username-based authentication. NFSv4 ACL set by users is stored as ACEs with UIDs and GIDs on the backend. When displayed on the NFSv4 ACL client, it automatically loads the local /etc/passwd to convert UIDs and GIDs into usernames and group names. You need to manage the mapping between usernames and UIDs and GIDs across multiple machines to ensure that the same username or group name maps to the same UID and GID, to prevent errors.

Supports outputting NFSv4 ACL via Extended Attributes.

Run the command
```
getfattr -n system.nfs4_acl file
```

Example output

# file: file
system.nfs4_acl=0sAAAABgAAAAAAAAAAABYBhwAAAAZPV05FUkAAAAAAAAAAAAAAABIAhwAAAAZHUk9VUEAAAAAAAAAAAAAAABIAhwAAAAlFVkVSWU9ORUAAAAAAAAAAAAAAAAAAAAEAAAAEMTAwMAAAAAAAAAALAAAAAwAAAAQxMDAwAAAAAAAAAEAAFgGQAAAABTEwMDAxAAAA

Supports migrating NFSv4 ACL using tools such as cp.
Alibaba Cloud NAS supports using the cp, tar, and rsync tools mentioned in How to preserve NFS v4 ACLs via extended attributes when copying file to migrate NFSv4 ACL.
In the following examples, cp --preserve=xattr file1 file2 copies the ACL when copying file1 to file2. cp -ar dir1 dir2 copies the ACL when copying dir1 to dir2.
Note
The rsync tool may not be able to migrate NFSv4 ACL if the version is lower than 3.1.2.
- Example 1: Migrating file ACL.
  1. Run the nfs4_getfacl file1 command to view the ACL permissions of file1.
```
# file: file1
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
A::1000:rtncy
```
  2. Run the cp --preserve=xattr file1 file2 command to copy the ACL of file1 to file2.
  3. Run the nfs4_getfacl file2 command to view the ACL permissions of file2.
```
# file: file2
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
A::1000:rtncy
```
- Example 2: Migrating directory ACL.
  1. Run the nfs4_getfacl dir1 command to view the ACL permissions of the dir1 directory.
```
# file: dir1
A::OWNER@:rwaDxtTnNcCy
A::GROUP@:rxtncy
A::EVERYONE@:rxtncy
A::1000:rxtncy
```
  2. Run the cp -ar dir1 dir2 command to copy the ACL of dir1 to dir2.
  3. Run the nfs4_getfacl dir2 command to view the ACL permissions of the dir2 directory.
```
# file: dir2
A::OWNER@:rwaDxtTnNcCy
A::GROUP@:rxtncy
A::EVERYONE@:rxtncy
A::1000:rxtncy
```
Supports interoperability between NFSv4 ACL and mode. Modifying the ACL may change the mode, and vice versa.
For example, if the current mode of file is 0666, the file permission and ACL permission examples are as follows.
- Run the ls -l file command to view the file permissions.
```
-rw-rw-rw-. 1 root root 0 May 3 2019 file
```
- Run the nfs4_getfacl file command to view the ACL permissions of the file.
```
# file: file
A::OWNER@:rwatTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
```
By setting the mode to add execute permission for owner, the corresponding ACE also gains execute permission. The following is an example:
1. Run the chmod u+x file command to add execute permission for owner.
2. Run the ls -l file command to view the file permissions.
```
-rwxrw-rw-. 1 root root 0 May 3 2019 file
```
3. Run the nfs4_getfacl file command to confirm that execute permission has been added for owner.
```
# file: file
A::OWNER@:rwaxtTcCy
A::GROUP@:rwatcy
A::EVERYONE@:rwatcy
```
By setting the ACE to add execute permission for group, the corresponding mode also gains execute permission.
1. Run the nfs4_setfacl -a A::GROUP@:x file command to add execute permission for group.
2. Run the ls -l file command to view the file permissions.
```
-rwxrwxrw-. 1 root root 0 May 3 2019 file
```
Note
- In interoperability, the ACL's everyone is equivalent to other in UNIX mode. Modifying mode other directly modifies ACE EVERYONE, which has a slight impact on permission semantics. For example: if the current mode is rw-------, after running chmod o+r, everyone including owner and group will gain read permission due to ACE EVERYONE + r; whereas in pure UNIX mode, owner and group still do not have read permission.
- When NFSv4 ACL has not been set, mode other still retains the semantics of other. After NFSv4 ACL is set, mode other changes to the semantics of everyone and maintains the everyone semantics. It is strongly recommended not to use mode after using NFSv4 ACL.

The correspondence between mode and NFSv4 ACL permissions.

When the chmod command is used to change the mode, the NFSv4 ACL changes correspondingly as shown in the following table.

other

mode other	NFSv4 ACL EVERYONE on file	NFSv4 ACL EVERYONE on dir
---	A::EVERYONE@:tncy	A::EVERYONE@:tncy
--x	A::EVERYONE@:xtncy	A::EVERYONE@:xtncy
-w-	A::EVERYONE@:watncy	A::EVERYONE@:waDtncy
-wx	A::EVERYONE@:waxtncy	A::EVERYONE@:waDxtncy
r--	A::EVERYONE@:rtncy	A::EVERYONE@:rtncy
r-x	A::EVERYONE@:rxtncy	A::EVERYONE@:rxtncy
rw-	A::EVERYONE@:rwatncy	A::EVERYONE@:rwaDtncy
rwx	A::EVERYONE@:rwaxtncy	A::EVERYONE@:rwaDxtncy

group

mode group	NFSv4 ACL GROUP on file	NFSv4 ACL GROUP on dir
---	A::GROUP@:tncy	A::GROUP@:tncy
--x	A::GROUP@:xtncy	A::GROUP@:xtncy
-w-	A::GROUP@:watncy	A::GROUP@:waDtncy
-wx	A::GROUP@:waxtncy	A::GROUP@:waDxtncy
r--	A::GROUP@:rtncy	A::GROUP@:rtncy
r-x	A::GROUP@:rxtncy	A::GROUP@:rxtncy
rw-	A::GROUP@:rwatncy	A::GROUP@:rwaDtncy
rwx	A::GROUP@:rwaxtncy	A::GROUP@:rwaDxtncy

owner

mode owner	NFSv4 ACL OWNER on file	NFSv4 ACL OWNER on dir
---	A::OWNER@:tTnNcCy	A::OWNER@:tTnNcCy
--x	A::OWNER@:xtTnNcCy	A::OWNER@:xtTnNcCy
-w-	A::OWNER@:watTnNcCy	A::OWNER@:waDtTnNcCy
-wx	A::OWNER@:waxtTnNcCy	A::OWNER@:waDxtTnNcCy
r--	A::OWNER@:rtTnNcCy	A::OWNER@:rtTnNcCy
r-x	A::OWNER@:rxtTnNcCy	A::OWNER@:rxtTnNcCy
rw-	A::OWNER@:rwatTnNcCy	A::OWNER@:rwaDtTnNcCy
rwx	A::OWNER@:rwaxtTnNcCy	A::OWNER@:rwaDxtTnNcCy

When the nfs4_setfacl command is used to change the NFSv4 ACL, if the file permission is being modified and the NFSv4 ACL attributes wa are not both present, the mode will not display the w attribute.
When the nfs4_setfacl command is used to change the NFSv4 ACL, if the directory permission is being modified and the NFSv4 ACL attributes waD are not all present, the mode will not display the w attribute.
If a directory NFSv4 ACL has Dx permissions, the mode shows no w attribute at this time, but the directory can still create and delete child files and child directories, which is equivalent to having the wx attributes in mode.
When using nfs4_setfacl, it is best to set permissions using uppercase RWX. Uppercase RWX automatically maps to the rwx in mode, avoiding compatibility issues between NFSv4 ACL and mode.

NFSv4 ACL supports richer permission definitions than mode, with each permission bit having a different function. In practice, some permission functions require multiple permission bits to be present simultaneously to take effect, and some permission bits need other permission bits to be expressed. For files and directories, the same permission bit may also have different functions. For NFSv4 ACL permissions for files and directories, see NFSv4 ACL.

Note

The default minimum permission for OWNER is: tTnNcCy. Permissions less than this are not allowed.
The default minimum permission for GROUP and EVERYONE is: tncy. Permissions less than this are not allowed.

Supports interoperability between NFSv4 ACL and POSIX ACL.
You can mount a file system containing NFSv4 ACL using the NFSv3 protocol, after which the NFSv4 ACL is converted to POSIX ACL. You can also mount a file system containing POSIX ACL using the NFSv4 protocol, after which the POSIX ACL is converted to NFSv4 ACL.
Note
Since the semantics of POSIX ACL and NFSv4 ACL are not fully identical—for example, POSIX ACL inheritance does not distinguish between files and directories, and POSIX ACL permissions are limited to rwx while NFSv4 ACL is richer—it is strongly recommended to use only NFSv4 ACL or only POSIX ACL, and to avoid mixing them as much as possible.
Assume that dir0 has been set with NFSv4 ACL, with permissions as follows.
- Run the command to get the permissions of dir0.
```
sudo nfs4_getfacl dir0
```
- Example output
```
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
```
The permissions of dir0 for POSIX ACL are as follows.
- Run the command
```
sudo getfacl dir0
```
- Example output
```
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::---
```
Assume that dir0/file has been set with NFSv4 ACL permissions as follows.
- Run the command
```
sudo nfs4_getfacl dir0/file
```
- Example output
```
A::OWNER@:tTnNcCy
A::GROUP@:tncy
A::EVERYONE@:tncy
A:g:19064:rxtncy
A:g:19065:rwaxtTnNcCy
```
The permissions of dir0/file for POSIX ACL are as follows.
- Run the command
```
sudo getfacl dir0/file
```
- Example output
```
user::---
group::---
group:players:r-x
group:adminis:rwx
mask::rwx
other::---
```
NFSv4 ACL count limit.
By default, Alibaba Cloud NAS supports a maximum of 100,000 non-identical ACLs per file system, and a maximum of 500 ACEs per ACL.
Note
Avoid overusing ACLs and ACEs to reduce the time and resources consumed during permission evaluation.

NAS POSIX ACL features

The permissions of other apply to everyone.
This includes user, group, and all users appearing in the ACEs, which is equivalent to everyone in NFSv4 ACL.
Note
It is strongly recommended to grant other only the minimum permission under all circumstances.
For example, the myfile file has the following ACL. Although the ACE containing alice does not have write permission, user alice still has write permission because other has write permission. The following is an example:
- Run the command
```
getfacl myfile
```
- Return information
```
# file: myfile
# owner: root
# group: root
user::rw-
user:alice:r--
group::r--
mask::r--
other::rw-
```
Running the chmod command does not modify ACEs that are not mode-based.
Note
For files with POSIX ACL set, avoid modifying the mode whenever possible. Use ACL modification to set permissions instead.
For example, the myfile file has an ACE that grants the group players read/write permissions. The following is an example:
- Run the command
```
getfacl myfile
```
- Return information
```
# file: myfile
# owner: root
# group: root
user::rw-
user:player:rw-
group::rw-
group:players:rw-
mask::rw-
other::---
```
After running chmod g-w myfile or chmod u-w myfile, the permissions of user player and group players are not modified. This differs from POSIX ACL specification, but it ensures that modifying the mode does not affect the permissions of non-generic users and groups set by POSIX ACL. The following is an example:
- Run the command
```
getfacl myfile
```
- Return information
```
# file: myfile
# owner: root
# group: root
user::r--
user:player:rw-
group::r--
group:players:rw-
mask::rw-
other::---
```
If neither group nor other has execute permission (x) on the file, the execute permission in the ACE also has no effect.
This is determined by the customer's Linux system. Although the NAS server returns an allow result for execute, the NAS client requires that group or other must have execute permission for execution to be truly allowed.
For example, if neither group nor other has execute permission on the myfile file, user player also cannot execute the file. The following is an example:
- Run the command
```
getfacl myfile
```
- Return information
```
# file: myfile
# owner: root
# group: root
user::rw-
user:player:r-x
group::r--
mask::r-x
other::r--
```
If group has execute permission, then user player also has execute permission. The following is an example:
- Run the command
```
getfacl myfile
```
- Return information
```
# file: myfile
# owner: root
# group: root
user::rw-
user:player:r-x
group::r-x
mask::r-x
other::r--
```
If inheritable NFSv4 ACL is set on a directory, this behavior may not comply with the POSIX ACL standard under NFSv3.
This is because NFSv4 ACL inheritance can be divided into file inheritance and directory inheritance, whereas POSIX ACL inherits for both files and directories.
Note
It is recommended that you avoid mixing NFSv4 ACL and POSIX ACL, and use only one NFS version for mounting a file system.
Modifying the Mask value is not supported.
The Mask value of NAS POSIX ACL is generated by the union of permissions of all users and groups. It has no practical significance and will not be modified.
The mapping of usernames to UIDs and GIDs across multiple machines must be maintained by yourself.
Currently, Alibaba Cloud NAS NFS authentication uses IP security groups and does not support username-based authentication. The POSIX ACL you set is stored as ACEs with user UIDs and GIDs on the backend. When displayed on the POSIX ACL client, it automatically loads the local /etc/passwd to convert UIDs and GIDs into usernames and group names. You need to manage the mapping between usernames and UIDs and GIDs across multiple machines to ensure that the same username or group name maps to the same UID and GID, to prevent errors.

Supports outputting POSIX ACL via Extended Attributes.

Run the command

getfattr -n system.posix_acl_access file

Example output

# file: file
system.posix_acl_access=0sAgAAAAEAAAD/////AgAFACAEAAAEAAAA/////xAABQD/////IAABAP////8=

Supports migrating POSIX ACL using tools such as cp.
Alibaba Cloud NAS supports using the cp, tar, and rsync tools mentioned in How to preserve NFS v4 ACLs via extended attributes when copying file to migrate POSIX ACL.
In the following examples, cp --preserve=xattr file1 file2 copies the ACL when copying file1 to file2. cp -ar dir1 dir2 copies the ACL when copying dir1 to dir2.
Note
The rsync tool may not be able to migrate POSIX ACL if the version is lower than 3.1.2.
- Example 1: Migrating file ACL permissions.
  1. Run the getfacl file1 command to view the ACL permissions of file1.
```
# file: file1
# owner: root
# group: root
user::rw-
user:player:r--
group::r--
mask::r--
other::r--
```
  2. Run the cp --preserve=xattr file1 file2 command to copy the ACL of file1 to file2.
  3. Run the getfacl file2 command to view the ACL permissions of file2.
```
# file: file2
# owner: root
# group: root
user::rw-
user:player:r--
group::r--
mask::r--
other::r--
```
- Example 2: Migrating directory ACL.
  1. Run the getfacl dir1 command to view the ACL permissions of dir1.
```
# file: dir1
# owner: root
# group: root
user::rwx
user:player:r-x
group::r-x
mask::r-x
other::r-x
```
  2. Run the cp -ar dir1 dir2 command to copy the ACL of dir1 to dir2.
  3. Run the getfacl dir2 command to view the ACL permissions of dir2.
```
# file: dir2
# owner: root
# group: root
user::rwx
user:player:r-x
group::r-x
mask::r-x
other::r-x
```
POSIX ACL count limit.
By default, Alibaba Cloud NAS supports a maximum of 100,000 non-identical ACLs per file system, and a maximum of 500 ACEs per ACL.
Note
Avoid overusing ACLs and ACEs to reduce the time and resources consumed during permission evaluation.

FAQ

Why is the Deny ACE type not supported?

The position of an ACE within an ACL is decisive.
NFSv4 ACL does not enforce ACE ordering, and Deny can be placed at any position. Suppose an ACL has two ACEs (A::Alice:r and D::Alice:r); the order of the two ACEs directly determines whether Alice has read permission.
Note
When setting the ACL, you must pay close attention to the position of each ACE.
The number of ACEs in the ACL grows rapidly.
Because there is no enforced ACE ordering, ACEs in an ACL list are difficult to merge and deduplicate. Adding ACEs to an ACL over time can cause it to grow to dozens or hundreds of ACEs, requiring a full scan of all ACEs when evaluating permission control results, which is time-consuming and resource-intensive.
Because mode does not have a Deny function, using Deny makes the interoperability between ACL and mode more complex.
- When Deny is present, if the mode changes, multiple ACEs may need to be added to the ACL. For example: to change the mode to -rw-rw-rw, the following content needs to be added in order at the head of the ACL.
```
A::OWNER@:rw
D::OWNER@:x
A::GROUP@:rw
D::GROUP@:x
A::EVERYONE@:rw
D::EVERYONE@:x
```
- If there is no Deny, ACEs can be ordered and deduplicated without distinguishing between everyone and other; if the mode changes, modifying the ACL is also very convenient — just find the ACEs for owner, group, and everyone and change them to the following content.
```
A::OWNER@:rw
A::GROUP@:rw
A::EVERYONE@:rw
```
NFSv4 ACL and POSIX ACL cannot be mutually converted.
POSIX ACL does not support Deny. If an NFSv4 ACL contains Deny, it cannot be converted to POSIX ACL.