Home > Storage > PowerScale (Isilon) > Product Documentation > Security and Compliance > Access Control Lists on Dell EMC PowerScale OneFS > Linux POSIX ACL and NFSv3
On common question is if NFSv3 is compatible with POSIX ACL. There is no ACL specification defined in the NFSv3 RFC document, so OneFS does not support POSIX ACL for NFSv3. In OneFS, you can only use POSIX mode bits while using NFSv3.
This section introduces how POSIX ACL works and includes examples.
Traditionally, Linux uses a simple file-system permission model. The model defines three classes of users: owner, group, and other. Each user class is granted a set of permissions. The permissions defined are read (r), write (w), and execute (x). This model is usually referred as POSIX mode bits. The ls -l command displays the permissions. For example, -rw-rw-r-- indicates a file with read and write access for owner, read and write access for group, and read access only for other.
For a more granular access control, many Linux operating systems have implemented ACLs based on the POSIX 1003.1e/1003.2c Draft Standard 17. This ACL is known as POSIX ACL. These ACLs were added to Linux kernel version 2.5.46 in November 2002. This is an extended scheme for the traditional mode-bits permission model. Each ACL consists of a list of ACEs. Each of the three classes of users in POSIX mode bits is represented by an ACE. Additional ACEs can be added to grant permission for additional users or groups.
There are two types of POSIX ACL:
Each POSIX ACL entry is formed with the format type:qualifier:permissions, and the qualifiers are undefined for owner, group, mask, and other. As Table 21 shows, there are six types of POSIX ACL entries.
Entry type | Text format |
owner | user::rwx |
named user | user:username:rwx |
owning group | group::rwx |
named group | group:groupname:rwx |
mask | mask::rwx |
other | other::rwx |
POSIX ACLs consist of three entries (owner, group, other) that are called minimal ACLs, and they are equivalent with POSIX mode bits. POSIX ACLs with more than the three entries are called extended ACLs. Extended ACLs consists of additional mask entry, named user, and named group entries.
As Figure 53 shows, named user and named group entries belong to the group class, which already contains the owning group entry. In the extended ACL, the group class permissions alone are not expressive enough to represent all the ACL entries permissions it contains. The mask entry is defined to solve this problem. It redefines the group class to represent an upper bound of the permissions. With minimal ACLs, the group class permissions map to the owning group entry permissions. With extended ACLs, the group class permissions are mapped to the mask entry permissions, whereas the owning group entry still defines the owning group permissions.
The default ACL is used to determine the newly created file and directory permissions, and the umask and mode parameters are also used to calculate their initial permissions. The mode parameter contains nine permission bits that stand for the permissions of the owner, group, and other class permissions. By default, the umask value is 022, and the mode value is 666 for touch command and 777 for mkdir command. Here is the algorithm for the initial access ACL of a new file or directory.
The following examples illustrate POSIX ACL and POSIX mode bits.
Example 1: Effective permissions when the parent has no default ACL
Create a parent directory without a default ACL, as shown as Figure 54.
Create a sub-directory under p_dir. Because the parent directory has no default ACL, the initial access ACL for the sub_dir is based on result of permission defined in mode (777), minus the permissions defined in umask (022). The initial permission is 755, which stands for rwx for owner, r-x for group, and r-x for other. See Figure 55.
Now, add a named user ACL entry to give read, write, and execute permissions to user jane on directory sub_dir. To do this, use the setfacl command with the –m option. Meanwhile, the mask ACL entry is autogenerated as needed. See Figure 56.
Using the ls command to check the POSIX mode bits again, the mask ACL entry maps to the group class permissions. However, the permissions for the owning group are still r-x. An additional + character is displayed after the permissions of all files that have extended ACLs.
Now, use the chmod command to modify the group class permissions as shown in. If no mask entry exists, chmod modifies the permissions of the owning group entry as it does traditionally. This example removes write access from the group class as shown in Figure 58. If an ACL entry contains permissions that are disabled by the mask entry, getfacl adds a comment that shows the effective set of permissions granted by that entry.
Example 2: Parent directory default ACL
Create a parent directory that has a default ACL as shown in Figure 59. Use the setfacl command with the –d option to modify default ACL. This example only adds an ACL entry for the stu_gp group in the setfacl command. The other entries require entries for owner, owning group, and others are automatically copied from the current access ACL to the default ACL.
Now, create a new directory under the parent directory p_dir. When creating new directory with mkdir, the command uses 777 as the mode value by default, so the parent directory’s default value is inherited as the initial access ACL and default ACL of the sub_dir directory.
Similarly, create a new file under the parent directory p_dir. When creating the new file with the touch command, the mode value is 666 by default, so the effective permissions of each class are set to the intersection of the permissions defined in the default ACL and the permissions defined in the mode parameter.