Data Access in OneFS - Part 1: Introduction to OneFS File Permissions
Thu, 16 Jun 2022 20:29:24 -0000
|Read Time: 0 minutes
About this blog series
Have you ever been confused about PowerScale OneFS file system multi-protocol data access? If so, this blog series will help you out. We’ll try to demystify OneFS multi-protocol data access. Different Network Attached Storage vendors have different designs for implementing multi-protocol data access. In OneFS multi-protocol data access, you can access the same set of data consistently with different operating systems and protocols.
To make it simple, the overall data access process in OneFS includes:
- When a client user tries to access OneFS cluster data by means of protocols (such as SMB, NFS, and S3), OneFS must first authenticate the client user.
- When the authentication succeeds, OneFS checks whether the user has permission on file share, where the access level depends on your access protocol, such as SMB share, NFS export, or S3 bucket.
- Only when the user is authorized to have permission on the file shares will OneFS apply user mapping rules and generate an access token for the user in most cases. The access token contains the following information:
- The user's Security Identifier (SID), User Identifier (UID), and Group Identifier (GID).
- The user's supplemental groups
- The user's role-based access control (RBAC) privileges
Finally, OneFS enforces the permissions on the target data for the user. This process evaluates the file permissions based on the user's access token and file share level permissions.
Does it sound simple but some details still confusing? Like, what exactly are UIDs, GIDs, and SIDs? What’s an access token? How does OneFS evaluate the file permissions? and so on. Don’t worry if you are not familiar with these concepts. Keep reading and we’ll explain!
To make it easier, we will start with OneFS file permissions, and then introduce OneFS access tokens. Finally, we will see how data access depends on the protocol you use.
In this blog series, we’ll cover the following topics:
- Data Access in OneFS - Part 1: Introduction to OneFS File Permissions
- Data Access in OneFS - Part 2: Introduction to OneFS Access Tokens
- Data Access in OneFS - Part 3: Why Use Different Protocols?
- Data Access in OneFS - Part 4: Using NFSv3 and NFSv4.x
- Data Access in OneFS - Part 5: Using SMB
- Data Access in OneFS - Part 6: Using S3
- More to add…
Now let's have a look at OneFS file permissions. In a multi-protocol environment, the OneFS operating system is designed to support basic POSIX mode bits and Access Control Lists (ACLs). Therefore, two file permission states are designated:
- POSIX mode bits - authoritative with a synthetic ACL
- OneFS ACL - authoritative with approximate POSIX mode bits
POSIX mode bits - authoritative with a synthetic ACL
POSIX mode bits only define three specific permissions: read(r), write(w), and execute(x). Meanwhile, there are three classes to which you can assign permissions: Owner, Group, and Others.
- Owner: represents the owner of a file/directory.
- Group: represents the group of a file/directory.
- Others: represents the users who are not the owner, nor a member of the group.
The ls -le command displays a file’s permissions; the ls -led command displays a directory’s permissions. If it has these permissions:
-rw-rw-r--
then:
-rw-rw-r-- means that the owner has read and write permissions
-rw-rw-r-- means that the group has read and write permissions
-rw-rw-r-- means that all others have only read permissions
In the following example for the file posix-file.txt, the file owner Joe has read and write access permissions, the file group Market has read and write access permissions, and all others only have read access permissions.
Also displayed here is the synthetic ACL (shown beneath the SYNTHETIC ACL flag) which indicates that the file is in the POSIX mode bit file permission state. There are three Access Control Entities (ACEs) created for the synthetic ACL, all of which is another way of representing the file’s POSIX mode bits permissions.
vonefs-aima-1# ls -le posix-file.txt -rw-rw-r-- 1 Joe Market 65 May 28 02:08 posix-file.txt OWNER: user:Joe GROUP: group:Market SYNTHETIC ACL 0: user:Joe allow file_gen_read,file_gen_write,std_write_dac 1: group:Market allow file_gen_read,file_gen_write 2: everyone allow file_gen_read
When OneFS receives a user access request, it generates an access token for the user and compares the token to the file permissions – in this case, the POSIX mode bits.
OneFS ACL authoritative with approximate POSIX mode bits
In contrast to POSIX mode bits, OneFS ACLs support more expressive permissions. (For all available permissions, which are listed in Table 1 through Table 3 of the documentation, see Access Control Lists on Dell EMC PowerScale OneFS.) A OneFS ACL consists of one or more Access Control Entries (ACEs). A OneFS ACE contains the following information:
- ACE index: indicates the ACE order in an ACL
- Identity type: indicates the identity type, supported identity type including user, group, everyone, creator_owner, creator_group, or owner_rights
- Identity ID: in OneFS, the UID/GID/SID is stored on disk instead of user names or group names. The name of a user or group is for display only.
- ACE type: The type of the ACE (allow or deny)
- ACE permissions and inheritance flags: A list of permissions and inheritance flags separated by commas
For example, the ACE "0: group:Engineer allow file_gen_read,file_gen_execute" indicates that its index is 0, and allows the group called Engineer to have file_gen_read and file_gen_execute access permissions.
The following example shows a full ACL for a file. Although there is no SYNTHETIC ACL flag, there is a "+" character following the POSIX mode bits that indicates that the file is in the OneFS real ACL state. The file’s OneFS ACL grants full permission to users Joe and Bob. It also grants file_gen_read and file_gen_execute permissions to the group Market and to everyone. In this case, the POSIX mode bits are for representation only: you cannot tell the accurate file permissions from the approximate POSIX mode bits. You should therefore always rely on the OneFS ACL to check file permissions.
vonefs-aima-1# ls -le acl-file.txt -rwxrwxr-x + 1 Joe Market 69 May 28 01:08 acl-file.txt OWNER: user:Joe GROUP: group:Market 0: user:Joe allow file_gen_all 1: group:Market allow file_gen_read,file_gen_execute 2: user:Bob allow file_gen_all 3: everyone allow file_gen_read,file_gen_execute
No matter the OneFS file permission state, the on-disk identity for a file is always a UID, a GID, or an SID. So, for the above two files, file permissions stored on disk are:
vonefs-aima-1# ls -len posix-file.txt -rw-rw-r-- 1 2001 2003 65 May 28 02:08 posix-file.txt OWNER: user:2001 GROUP: group:2003 SYNTHETIC ACL 0: user:2001 allow file_gen_read,file_gen_write,std_write_dac 1: group:2003 allow file_gen_read,file_gen_write 2: SID:S-1-1-0 allow file_gen_read vonefs-aima-1# ls -len acl-file.txt -rwxrwxr-x + 1 2001 2003 69 May 28 01:08 acl-file.txt OWNER: user:2001 GROUP: group:2003 0: user:2001 allow file_gen_all 1: group:2003 allow file_gen_read,file_gen_execute 2: user:2002 allow file_gen_all 3: SID:S-1-1-0 allow file_gen_read,file_gen_execute
When OneFS receives a user access request, it generates an access token for the user and compares the token to the file permissions. OneFS grants access when the file permissions include an ACE that allows the identity in the token to access the file, and does not include an ACE that denies the identity access.
When evaluating the file permission for a user's access token, OneFS checks the ACEs one by one by following the ACEs index order and stops checking when the following conditions are met:
- All of the required permissions for the user access request are allowed by ACLs, and the access request is authorized.
- Any one of the required permissions for the user access request is explicitly denied by ACLs, and the access request is denied.
- All ACEs have been checked, but not all required permissions for the user access request are allowed by ACLs, then the access request is also denied.
Let’s say we have a file named acl-file01.txt that has the file permissions shown below. When user Bob tries to read the data of the file, OneFS checks the ACEs from index 0 to index 3. When checking ACE index 1, it explicitly denies Bob read data permissions. The ACLs then stop checking, and read access is denied.
vonefs-aima-1# ls -le acl-file01.txt -rwxrw-r-- + 1 Joe Market 12 May 28 06:19 acl-file01.txt OWNER: user:Joe GROUP: group:Market 0: user:Joe allow file_gen_all 1: user:Bob deny file_gen_read 2: user:Bob allow file_gen_read,file_gen_write 3: everyone allow file_gen_read
Now let’s say that we still have the file named acl-file01.txt, but the file permissions are now a little different, as shown below. When user Bob tries to read the data of the file, OneFS checks the ACEs from index 0 to index 3. When checking ACE index 1, it explicitly allows Bob to have read permissions. The ACLs checking process therefore ends, and read access is authorized. Therefore, it is recommended to put all “deny” ACEs in front of “allow” ACEs if you want to explicitly deny specific permissions for specific users/groups.
vonefs-aima-1# ls -le acl-file01.txt -rwxrw-r-- + 1 Joe Market 12 May 28 06:19 acl-file01.txt OWNER: user:Joe GROUP: group:Market 0: user:Joe allow file_gen_all 1: user:Bob allow file_gen_read,file_gen_write 2: user:Bob deny file_gen_read 3: everyone allow file_gen_read
File permission state changes
As mentioned before, a file can only be in one state at a time. However, the file permission state of the file may be flipped. If a file is in POSIX, it can be flipped to an ACL file by modifying the permissions using SMB/NFSv4 clients or by using the chmod command in OneFS. If a file is in ACL, it can be flipped to a POSIX file, by using the OneFS CLI command: chmod –b XXX <filename>. The ‘XXX’ specifies the new POSIX permission. For more examples, see File permission state changes.
Now, you should be able to check a file’s permission on OneFS with the command ls -len filename, and check a directory’s permissions on OneFS with the command ls -lend directory_name.
In my next blog, we will cover what an access token is and how to check a user’s access token!
Resources
Author: Lieven Lin