File System Access Control Lists
IBM Spectrum Scale supports Access Control Lists (ACLs) to provide fine-grained access control to files and directories. While the file system supports two different types of ACLs (NFSv4 and POSIX), only NFSv4 ACLs are supported for the SMB protocol, and NFSv4 ACLs are recommended for general protocol usage. The reason behind this is that the NFS protocol uses NFSv4 ACLs natively, and the ACLs in the SMB protocol (also called “Security Descriptors”) can be mapped directly to and from the NFSv4 ACL stored in the file system.
Access Control Lists for Object Protocols
Both object protocols supported in IBM Spectrum Scale (Openstack Swift and the S3 API) also support different access control lists. These are stored separately from the NFSv4 ACL used for SMB and NFS protocols. For files that are access through the S3 API, Openstack Swift and file services, three different ACLs are stored, and each applies to the corresponding access method. The rest of this entry will focus on NFSv4 ACLs and their use for providing access control for file protocol use.
NFSv4 Access Control Lists
Each file or directory in the file system grants permissions according to an ACL. Each ACL consists of one or more Access Control Entries (ACE). Each ACE allows or denies certain permissions to a principal (the user or group specified in the ACE). When the file system has to determine whether a user has been granted a requested set of permissions, the ACEs are evaluated in the order in which they are specified in the ACL. NFSv4 ACLs default to “deny”; If a requested permission is not explicitly granted in any ACE, then the permission request is denied.
The NFSv4 standard also specifies “audit” and “alarm” ACEs, that can be used for auditing access. These ACEs are not supported with Spectrum Scale.
Inheritance in NFSv4 ACLs
Each entry in a NFSv4 ACL can be inherited. Inheritance only applies when new files or subdirectories are created in a directory, so this is like a template for new files and directories. In that case, all ACE entries from the directory that are marked as “inherit to file” or “inherit to directory” are put in the ACL of a newly created file or directory. The ACL entries in the directory can also be marked as “inherit only”, meaning that these entries will be inherited according to the inheritance flag, but they are not used for permission checks on the parent directory.
When a SMB client system (e.g. from the Security dialog on a Microsoft Windows system) requests to change the ACLs of a directory tree, the client has to walk the tree and change the ACL on each file or directory. Depending on the number of files and directories in that tree, this operation can take a long time.
When a file or directory is created in IBM Spectrum Scale where the parent directory does not have inheriting ACL entries, default permissions are set on the new file or directory. The default permissions are created according to the modebits from the call creating the file or directory and the active umask.
ACLs in the SMB protocol
Client systems accessing the Spectrum Scale cluster through the SMB protocol can also set and query ACLs; these SMB ACLs are also referred to as “Windows ACLs” or “Security Descriptors”. The SMB ACL consists of two parts: The discretionary access control list (DACL) consists of “allow” and “deny” entries that grant permissions, while system access control liste (SACL) is used to audit access, similar to the NFSv4 “alarm” and “audit” ACEs. Since Spectrum Scale does not support NFSv4 “alarm” and “audit” ACEs, it also does not support SACLs for SMB clients.
Principals in SMB ACL entries are security identifiers (SIDs). When accessing SMB exports in Spectrum Scale, the SMB service maps between the SMB ACEs and NFSv4 ACEs and also maps the SID principals to the corresponding users and groups. This requires that authentication and id mapping is configured correctly in the IBM Spectrum Scale cluster. Id mapping in IBM Spectrum Scale requires that the user and the user's primary group have a valid id mapping. Secondary groups do not need to have a valid id mapping; secondary groups are silently dropped if there is no valid id mapping. That is a point to keep in mind when using “deny” ACL entries, since that can result in the “deny” entry for a secondary group getting ignored, thus resulting in additional permissions for the user. When all secondary groups have a valid id mapping, this will not be an issue.
SMB client systems running the Microsoft Windows operating system require a “canonical” order in the ACE entries where non-inherited deny entries have to be listed first in the ACL, then non-inherited allow entries, then inherited deny entries and last inherited allow entries. When using Microsoft Windows clients, the easiest way to achieve this is managing the ACLs from a Microsoft Windows client.
ACLs in the NFS protocol
Clients connecting through the NFSv4 protocol can query and set the NFSv4 ACLs stored in the file system directly. Clients connecting through the NFSv3 protocol can only query the subset of ACL entries that map to the POSIX modebits, but access to files and directories will be enforced on the Spectrum Scale cluster according to the complete ACL.
Mapping between NFSv4 ACLs and SMB ACLs
IBM Spectrum Scale only stores one NFSv4 ACL per file or directory. When a SMB client requests the SMB ACL for a file or directory, the SMB service will read the NFSv4 ACL, map it to a SMB ACL and return that to the SMB client. Similarly when a SMB client writes a SMB ACL to a file or directory, the SMB service will map the SMB ACL to a NFSv4 ACL and store that in the file system. The principals in the ACL entries are mapped according to the configured id mapping in the IBM Spectrum Scale cluster.
The permissions in the SMB ACEs and NFSv4 ACEs can be mapped directly, as can be seen when comparing the available permission bits:
special:everyone@:----:allow:FileInherit:DirInherit
(-)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (-)SYNCHRONIZE (-)READ_ACL (-)READ_ATTR (-)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (-)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
“Traverse folder / execute file” in the SMB ACL maps to EXEC/SEARCH in the NFSv4 ACL, “List folder / read data” maps to “READ/LIST”, etc. The exceptions in this example are” “Full Control” in the Windows Permission Entry dialog which is not an actual permission bit, but only a shortcut to set all permission bits. The “SYNCHRONIZE” bit in the NFSv4 ACL maps to the SYNCHRONIZE bit in the SMB ACL, but this is not an actual permission that is checked and is not shown in the dialog.
The inheritance flags also map between the Windows client and the NFSv4 ACL: “Applies to: This folder, subfolder and files” maps to “FileInherit:DirInherit”.
The “claim based ACL” type is not supported in IBM Spectrum Scale.
Special ACL entries
Besides referring to an explicit user or group, principals in NFSv4 ACL entries can also refer to special entries:
special:owner@ grants permissions to the owner of the file. When mapping to a SMB ACL, a special:owner@ entry that is flagged with “Inherit” is mapped to the CREATOR OWNER principal.
special:group@ grants permissions to the owning group of the file. When mapping to a SMB ACL, a special:group@ entry that is flagged with “Inherit” is mapped to the CREATOR GROUP principal.
special:everyone@ is mapped to the “Everyone” principal in a SMB ACL.
Recommendations for Access Control Lists usage
When using access control lists for a larger set of file, some recommendations seen in typical scenarios:
- If the access to the data also includes access from Microsoft Windows client machines over the SMB protocol, then the ACL administration should be done from a Microsoft Windows client machine. That ensures that the additional ACL flags used by Microsoft Windows are present and that the order of the ACL entries is also the expected “canonical” order.
- Use the inheritance flags to have permissions inherited down from the root directory of an export.
- Avoid deny entries, since they cause additional complexity that can usually be avoided.
- Read the authorization limitations page in the Spectrum Scale knowledge center to be aware of product specific limitations in the handling of ACLs
Example
The concept of mapping the ACLs is best illustrated by an example. Given a directory that is both exported to SMB and NFS clients, ACLs can be set through any access method (SMB, NFS or direct file system access), and later retrieved. The standard approach for creating the share would be creatin the share directory and assigning an user as the owner that will manage the ACLs:
mkdir /ibm/fs1/test chown 'storage5test\administrator' /ibm/fs1/test mmsmb export add test /ibm/fs1/test mmnfs export add /ibm/fs1/test -c "*(Access_type=RW,SecType=none,squash=none)"
On the Windows client, access the SMB export as the specified user and navigate to the advanced security settings dialog for the SMB export (“Properties”->”Security” tab->”Advanced Button”). That will show the mapping of the initial permissions on the folder to a SMB ACL:
Remove these permissions and add the desired permissions to be inherited to new files and folders. An example would be:
Once the changes are applied, they are written to the NFSv4 ACL of the folder in the Spectrum Scale file system. This can be verified by reading the ACL directly from the file system; each entry maps to an entry in the ACL shown in the dialog above:
Once the changes are applied, they are written to the NFSv4 ACL of the folder in the Spectrum Scale file system. This can be verified by reading the ACL directly from the file system; each entry maps to an entry in the ACL shown in the dialog above:
# mmgetacl /ibm/fs1/test
#NFSv4 ACL
#owner:STORAGE5TEST\administrator
#group:root
#ACL flags:
# DACL_PRESENT
# DACL_AUTO_INHERITED
# SACL_AUTO_INHERITED
# DACL_PROTECTED
# NULL_SACL
user:STORAGE5TEST\administrator:rwxc:allow:FileInherit:DirInherit
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
group:STORAGE5TEST\domain admins:rwxc:allow:FileInherit:DirInherit
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
group:STORAGE5TEST\domain users:r-x-:allow:FileInherit:DirInherit
(X)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
special:owner@:rwxc:allow
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
special:owner@:rwxc:allow:FileInherit:DirInherit:InheritOnly
(X)READ/LIST (X)WRITE/CREATE (X)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (X)READ_NAMED
(X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL (X)WRITE_ATTR (X)WRITE_NAMED
special:everyone@:----:allow:FileInherit:DirInherit
(-)READ/LIST (-)WRITE/CREATE (-)APPEND/MKDIR (X)SYNCHRONIZE (X)READ_ACL (X)READ_ATTR (-)READ_NAMED
(-)DELETE (-)DELETE_CHILD (-)CHOWN (-)EXEC/SEARCH (-)WRITE_ACL (-)WRITE_ATTR (-)WRITE_NAMED
Clients accessing the IBM Spectrum Scale cluster through the NFSv4 protocol can also query the same ACL. Given a Linux system that has the NFSv4 export mounted on the /test directory, the same ACL can be queried through:
# nfs4_getfacl /test
A:fd:STORAGE5TEST\administrator@tuc.stglabs.ibm.com:rwaDdxtTnNcCoy
A:fdg:STORAGE5TEST\domain admins@tuc.stglabs.ibm.com:rwaDdxtTnNcCoy
A:fdg:STORAGE5TEST\domain users@tuc.stglabs.ibm.com:rxtncy
A::OWNER@:rwaDdxtTnNcCoy
A:fdi:OWNER@:rwaDdxtTnNcCoy
A:fd:EVERYONE@:tcy
SMB Export ACLs
For SMB exports, an additional ACL can be defined for each SMB export. IBM Spectrum Scale allows the administration of SMB export ACLs through the “mmsmb exportacl” command. This is a second set of ACLs, that is stored in the SMB server and does not map to the NFSv4 ACLs stored in the file system. To have access to a file or directory through the SMB protocol, a user needs to have sufficient permissions in the SMB export ACL and in the file system ACL. The default of the SMB export ACL is to allow any access, with this default only the file system ACLs are relevant for permission checking.
References
#IBMSpectrumScale#Softwaredefinedstorage