Home > Storage > PowerScale (Isilon) > Product Documentation > Security and Compliance > Access Control Lists on Dell EMC PowerScale OneFS > OneFS AIMA and file permission checking
OneFS authentication, identity management, and authorization (AIMA) provides OneFS cluster access control, and enables multiprotocol access with a unified permission. Figure 11 shows the anatomy of AIMA OneFS cluster access control.
When a user connects to a OneFS cluster through SmartConnect or node IPs in an IP pool, OneFS finds the associated access zone with the IP pool. Then, OneFS checks the directory services of the access zone. If OneFS finds an account that matches the user’s login name, OneFS verifies the user’s identity to authenticate the user. During authentication, OneFS creates an access token for the user and combines the user access token from different directory services based on user-mapping rules. The token contains the user’s full identity including group memberships. OneFS uses the token later to check access to directories and files according to the file permissions on disk.
For details about SmartConnect, user mapping, ID mapping, and the access token, refer to the documents PowerScale SmartConnect and Identities, Access Tokens, and the PowerScale OneFS User Mapping Service. This document focuses on file permissions on disk.
OneFS unites permissions models of different protocols to provide seamless and secure file-sharing across protocols and platforms. To provide this capability, OneFS must be able to maintain unified file permissions on disk. It must also present a protocol-specific view of permissions, such as presenting POSIX mode bits to NFSv3 clients and the protocol ACL for NFSv4/SMB clients. To do this action, OneFS implements the following design for a unified-permissions model.
Only one set of permissions (POSIX mode bits or OneFS real ACL) is authoritative to preserve a file’s original permissions. The view of file permissions from the PowerScale system can be in one of two states:
When a client accesses a OneFS cluster with different protocols, the OneFS internal file permissions are translated to a protocol-specific view of permissions for representation only. The access checking is always based on the OneFS internal file permission.
During the translation to SMB ACL, OneFS translates the internal ACL to a canonical ACL and sends it to SMB clients. A canonical ACL always places an explicit ACE before an inherited ACE, and always places a deny ACE before an allow ACE. The SMB ACL is implemented as a canonical ACL.
Since SMB clients are always presented with a reordered canonical ACL other than the actual ACL in OneFS, users need to be careful when editing ACLs through SMB.
The following example demonstrates editing an ACL through the Windows Explorer UI, and the permissions are not granted properly due to the order of the ACEs.
In this example, user01 is a member of group smbusers. For the directory top-dir, user 01 is given read, write, and execute permissions, the group smbusers is denied write permissions, and everyone else has read and execute permissions. The OneFS ACL shown in Figure 12:
As Error! Reference source not found. shows, when checking the ACL of the top-dir directory from Windows Explorer through the SMB protocol, the ACL representation is reordered and shown as a canonical ACL like SMB ACL. For now, the effective permission is still based on the actual OneFS ACL, and user01 still has write permissions on the directory top-dir.
This example now shows modifying the ACL in Windows Explorer to remove execute permission for everyone, and keeping the rest of the ACEs as-is. The result shown in Figure 14.
The Windows client sends back the canonical ACL, and when checking the ACL on the OneFS cluster using the ls –led command, the ACE order has been changed as shown as Error! Reference source not found.. The semantic of the new OneFS ACL is also changed, and it will deny write permissions for all smbusers group members, including user user01.
For OneFS 8.2.0 and earlier, when users use the nfs4_setfacl command to modify a file’s ACL through NFSv4 on OneFS 8.2.0 and earlier, the canonical ACL translation behavior also exists for NFSv4 clients, but users can place the ACE in the original order using the nfs4_setfacl –e option. Be careful when manipulating a OneFS file’s ACL through the SMB or NFSv4 protocol because OneFS will reorder on-disk permissions to be canonical before sending them to clients.
For OneFS 8.2.1 and above, no canonical ACL translation occurs for NFSv4 clients.
Note: For OneFS 8.2.0 and OneFS 8.1.2, Dell Technologies provides a patch to disable the canonical ACL translation behavior for NFSv4 clients. See the document Current PowerScale OneFS Patches for available patches.