Home > Storage > PowerScale (Isilon) > Product Documentation > Security and Compliance > Access Control Lists on Dell EMC PowerScale OneFS > OneFS ACL
OneFS provides a single namespace for multiprotocol access and it has its own internal ACL representation to perform access control. The internal ACL is presented as protocol-specific views of permissions so that NFS exports display POSIX mode bits for NFSv3, and shows ACL for NFSv4 and SMB.
When connecting to an PowerScale cluster with SSH, you can manage not only POSIX mode bits but also ACLs with standard UNIX tools such as chmod commands. In addition, you can edit ACL policies through the web administration interface to configure how OneFS manages permissions for networks that mix Windows and UNIX systems.
OneFS ACL design is derived from Windows NTFS ACL, and many concept definitions and operations are similar to the Windows NTFS ACL, such as ACE permissions and inheritance.
To deliver cross-protocol file access seamlessly, OneFS stores an internal representation of a file-system object’s permissions. The internal representation can contain information from the POSIX mode bits or the ACL.
OneFS has two types of ACLs to fulfill different scenarios:
In contrast to the Windows DACL and NFSv4 ACL, the OneFS ACL access control entry (ACE) adds an additional identity type. OneFS ACEs contain the following information:
Similar to the Windows permission level, OneFS divides permissions into the following three types:
The standard ACE permissions that can appear for a file-system object are shown in Table 1.
ACE permission | Applies to | Description |
std_delete | Directory or file | |
std_read_dac | Directory or file | The right to read the security descriptor, not including the SACL |
std_write_dac | Directory or file | The right to modify the DACL in the object's security descriptor |
std_write_owner | Directory or file | The right to change the owner in the object's security descriptor |
std_synchronize | Directory or file | The right to use the object as a thread synchronization primitive |
std_required | Directory or file | Maps to std_delete, std_read_dac, std_write_dac, and std_write_owner |
The generic ACE permissions that can appear for a file system object are shown in Table 2.
ACE permission | Applies to | Description |
generic_all | Directory or file | Read, write, and execute access. Maps to file_gen_all or dir_gen_all. |
generic_read | Directory or file | Read access. Maps to file_gen_read or dir_gen_read. |
generic_write | Directory or file | Write access. Maps to file_gen_write or dir_gen_write. |
generic_exec | Directory or file | Execute access. Maps to file_gen_execute or dir_gen_execute |
dir_gen_all | Directory | Maps to dir_gen_read, dir_gen_write, dir_gen_execute, delete_child, and std_write_owner. |
dir_gen_read | Directory | Maps to list, dir_read_attr, dir_read_ext_attr, std_read_dac, and std_synchronize. |
dir_gen_write | Directory | Maps to add_file, add_subdir, dir_write_attr, dir_write_ext_attr, std_read_dac, and std_synchronize. |
dir_gen_execute | Directory | Maps to traverse, std_read_dac, and std_synchronize. |
file_gen_all | File | Maps to file_gen_read, file_gen_write, file_gen_execute, delete_child, and std_write_owner. |
file_gen_read | File | Maps to file_read, file_read_attr, file_read_ext_attr, std_read_dac, and std_synchronize. |
file_gen_write | File | Maps to file_write, file_write_attr, file_write_ext_attr, append, std_read_dac, and std_synchronize. |
file_gen_execute | File | Maps to execute, std_read_dac, and std_synchronize. |
The constant ACE permissions that can appear for a file-system object are shown in Table 4.
Applies to | Description | |
modify | File | Maps to file_write, append, file_write_ext_attr, file_write_attr, delete_child, std_delete, std_write_dac, and std_write_owner |
file_read | File | The right to read file data |
file_write | File | The right to write file data |
append | File | The right to append to a file |
execute | File | The right to execute a file |
file_read_attr | File | The right to read file attributes |
file_write_attr | File | The right to write file attributes |
file_read_ext_attr | File | The right to read extended file attributes |
file_write_ext_attr | File | The right to write extended file attributes |
delete_child | Directory or file | The right to delete children, including read-only files within a directory; this is currently not used for a file, but can still be set for Windows compatibility |
list | Directory | |
add_file | Directory | The right to create a file in the directory |
add_subdir | Directory | The right to create a subdirectory |
traverse | Directory | The right to traverse the directory |
dir_read_attr | Directory | The right to read directory attributes |
dir_write_attr | Directory | The right to write directory attributes |
dir_read_ext_attr | Directory | The right to read extended directory attributes |
dir_write_ext_attr | Directory | The right to write extended directory attributes |
Inheritance allows permissions to be layered or overridden as needed in an object hierarchy and allows for simplified permissions management. The semantics of OneFS ACL inheritance meanings are the same as the Windows ACL inheritance, and they are easily understandable to someone familiar with the Windows NTFS ACL inheritance. Table 4 shows the ACE inheritance flags defined in OneFS.
ACE inheritance flag | Set on directory or file | Description |
Directory only | Indicates an ACE applies to the current directory and files within the directory | |
container_inherit | Directory only | Indicates an ACE applies to the current directory and subdirectories within the directory |
Directory only | Indicates an ACE applies to subdirectories only, files only, or both within the directory. | |
no_prop_inherit | Directory only | Indicates an ACE applies to the current directory or only the first-level contents of the directory, not the second-level or subsequent contents |
inherited_ace | File or directory | Indicates an ACE is inherited from the parent directory |
The following examples show how ACLs can be used with OneFS.
As mentioned in section 1.2.1, if a parent directory does not contain any inheritable ACL entries, a OneFS synthetic ACL will be generated in the following situations:
The example shown in Figure 1 connects to a cluster with SSH and creates a parent directory that has no inheritable ACL entries.
This example also creates a sub directory under the parent-dir directory using mkdir command, and checks the ACL of the sub directory. Shown in Figure 2, a OneFS synthetic ACL is generated according to the POSIX mode bits.
As mentioned in OneFS synthetic ACL and real ACL, a OneFS real ACL is initialized if the synthetic ACL is modified through SMB. The sub-dir directory ACL is edited through the Windows Explorer UI, shown in Figure 3. The first ACE is modified, and full-control permission is granted to the user.
Back to cluster, the OneFS ACL is verified again using ls –led command. This command shows that the OneFS synthetic ACL is changed to a OneFS real ACL and the allowed permission is changed to dir_gen_all, shown in Figure 4.
You can also initialize the OneFS real ACL by modifying the OneFS synthetic ACL using the NFSv4 client tool (nfs4_setfacl) and the enhanced chmod command tool on OneFS.
To manage and manipulate ACLs directly in OneFS, traditional ls and chmod command tools are retrofitted. They can be used to view and manage ACLs on OneFS, including adding, modifying, and deleting ACL entries. They also provide options to set ACL inheritance flags. This example shows how to use the retrofitted ls and chmod command tools to manage OneFS ACL.
To view the ACL of a file in OneFS, run the command ls –le or ls –len. To view the ACL of a directory in OneFS, run the command ls –led or ls –lend. The –n option in the command is used to display user and group IDs numerically rather than converting to a user or group name string.
Figure 5 shows the ACL of a directory. In the output, the + sign is added after the POSIX mode bits, indicating that a file or directory contains a OneFS real ACL.
This example adds an ACL entry to the directory using the chmod command with the +a# option. As Figure 6 shows, the ACL entry is placed in the ACL with index 1 and allows user01 to have the permissions of dir_gen_read and dir_gen_write for the top-dir directory.
To modify the ACL entry added previously, use the chmod command with the =a# option. Some shells require = to be escaped with the \ character. As Figure 7 shows, the ACL entry is modified only to grant the permission of dir_gen_read to user01.
To delete the ACL entry modified previously, use the chmod command with the –a# option, followed by an index of the ACE, shown in Figure 8.
This example adds an ACL entry with the object_inherit and container_inherit inheritance flags specified, which is similar to Windows (OI)(CI) flags. This applies the ACE to the current directory and propagates it to the subdirectories and files within the top-dir directory.
The next step created a new directory under top-dir. Error! Reference source not found. shows the ACE with the flags of object_inherit and container_inherit specified in the parent directory, which are propagated to the new directory. There is also an inherited_ace flag that indicates the ACE is inherited from parent directory and not explicit specified.