Authorizing file protocol users

ACLs on files and directories

With the SMB and NFS protocols, you can manage the ACL permissions on files and directories from connected file systems. ACLs from both protocols (NFS and SMB) are mapped to the same ACL in the file system. The ACL supports inheritance and you can control the inheritance by using the special inheritance flags.

It is a good practice to manage ACLs from the ACL management interface on a SMB or NFS client system. For example, after you create the directories for an SMB or NFS export, you can set the owner of the directory with the chown command. Then the user can connect to the export with the SMB or NFS protocol to see and manage the ACLs that are associated with the directory over which the export is created.

Setting ACLs from protocol clients allows using ACLs in exactly the format expected by the client. Especially Microsoft Windows Clients expect the ACL to be stored in a canonical order. To avoid problems with presenting differently ordered ACLs to these clients, manage the ACLs for SMB clients that run Microsoft Windows from a Microsoft Windows system.

ACLs and POSIX mode bits

The POSIX bits of a file or directory are another authorization method, different from ACLs. POSIX bits can also be used to specify access permissions for a file. You can use the POSIX bits of a file to configure access control for an owner, a group, and for all users to read, update, or run the file. POSIX bits are less flexible than ACLs.

As the file system only stores the NFSv4 ACL, changing the POSIX mode bits also modifies the ACL of an object. When you use ACLs for access control, consider how changes to POSIX mode bits should interact with the ACL. You can configure this behavior with the --allow-permission-change parameter of the mmcrfileset and mmchfileset commands.

An ACL extends the base permissions or the standard file access modes such as read, write, and execute. ACLs are compatible with UNIX mode bits. Issuing the chmod command by the NFS clients overwrite the access privileges that are defined in the ACL by the privileges that are derived from UNIX mode bits. By default, the ACLs are replaced by UNIX mode bits if the chmod command is submitted. To allow proper use of ACLs, it is a good practice to prevent chmod from overwriting the ACLs by setting the –allow-permission-change parameter of the mmcrfileset or mmchfileset command parameter to setAclOnly or cchmodAndUpdateAcl.

This is especially important for applications running on cluster nodes and for NFSv3 clients, as those will issue chmod calls to set the POSIX mode bits. These will be stored in the ACL, depending on the --allow-permission-change parameter.

The permissions from the NFSv4 ACL entries special:owner@ are shown as the POSIX permission bits for the file owner, special:group@ are shown as the POSIX permission bits for the group, and special:everyone@ are shown for the POSIX permissions for “other”.

SMB protocol share-level ACLs

SMB share ACLs apply only to SMB exports and they are separate from the file system ACLs. The default for share-level ACLs is granting full access to everybody, resulting only in the file system ACL determining access by default. When SMB share ACLs are set to restrict access, users accessing data through the SMB protocol need to have access in both, the share-level ACL and in the file system ACL.

SMB share ACLs can be changed either through the MMC on a Windows client or through the mmsmb exportacl command. For more information, see the mmsmb exportacl command on any protocol node.

Mapping between SMB protocol Security Descriptors and NFSv4 ACLs stored in the file system

The SMB protocol uses Security Descriptors to describe the permissions on a file or directory. The Discretionary Access Control Lists (DACL) from the Security Descriptors are mapped to and from the NFSv4 ACLs stored in the file system. That way, only one authoritative ACL exists for each file or directory.

The structure of NFSv4 ACLs and DACLs is similar. The ACL consists of a list of entries. Each entry contains the elements: The principal (the user or group the entry is referring to), inheritance flags, the type (allow or deny) and the permissions being granted or denied in this entry.

Depending on the configured id mapping method for a domain, the mapping from the Security Descriptor to the NFSv4 ACL is also done slightly differently. The reason here is that the –unixmap-domain and –ldapmap-domain methods strictly map the SID of an Active Directory user to a uid and the SID of an Active Directory group to a gid. The default internal mapping method that is used when no other method has been specified maps each Active Directory user or group to both, a uid and a gid with the same numeric value. That allows for file ownership of a group to be represented in the IBM Storage Scale file system.

When possible, the Security Descriptor entries matching owner or owning group are mapped to the NFSv4 ACL special:owner@ and special:group@ entries, so that the permissions are also reflected in the POSIX mode bits. This is not possible when the Security Descriptor entries have flags to be inherited to new files or folders, as inheriting the entries to new files or folders with different owner information would create unwanted entries.

Multiple ACL entries which are exact duplicates after the mapping is done are merged into one ACL entry.

Mapping between SMB protocol Security Descriptors and NFSv4 ACL with the --unixmap-domains or --ldapmap-domains id mappings

In this case, each user in Active Directory is mapped to a uid and each group in Active Directory is mapped to a gid. This carries the limitation that a file or directory cannot be owned by a group as the owner of an object in the IBM Storage Scale file system is always a uid, not a gid. The mapping of entries from an SMB Security Descriptor to a NFSv4 ACL in this case is done according to the following table:

Mapping between SMB protocol Security Descriptors and NFSv4 ACL with the internal id mapping

The default id mapping method creates id mappings based on an internal database on the CES protocol nodes. This id mapping method assigns both, a uid and a gid, to each SID. This has the advantage that files and objects can be owned by a group. This also affects the mapping from the Security Descriptor to the NFSv4 ACL, as most entries are now mapped to gid entries: