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
Related Blog Posts
Data Access in OneFS - Part 2: Introduction to OneFS Access Tokens
Fri, 01 Jul 2022 14:15:16 -0000
|Read Time: 0 minutes
Recap
In the previous blog, we introduced the OneFS file permission basics, including:
1. OneFS file permission is only in one of the following states:
- POSIX mode bits - authoritative with a synthetic ACL
- OneFS ACL - authoritative with approximate POSIX mode bits
2. No matter the OneFS file permission state, the on-disk identity for a file is always a UID, a GID, or an SID. The name of a user or group is for display only.
3. When OneFS receives a user access request, it generates an access token for the user and compares the token to the file permissions based on UID/GID/SID.
Therefore, in this blog, we will explain what UID/GID/SID is, and will explain what a OneFS access token is. Now, let’s start by looking at UID/GID/SIDs.
UID/GID and SID
In our daily life, we are usually familiar with a username or a group name, which stands for a user or a group. In a NAS system, we use UID, GID, and SID to identify a user or a group, then the NAS system will resolve the UID, GID, and SID into a related username or group name.
The UID/GID is usually used in a UNIX environment to identify users/groups with a positive integer assigned. The UID/GID is usually provided by the local operating system and LDAP server.
The SID is usually used in a Windows environment to identify users/groups. The SID is usually provided by the local operating system and Active Directory (AD). The SID is written in the format:
(SID)-(revision level)-(identifier-authority)-(subauthority1)-(subauthority2)-(etc)
for example:
S-1-5-21-1004336348-1177238915-682003330-512
For more information about SIDs, see the Microsoft article: What Are Security Identifiers?.
OneFS access token
In OneFS, information about users and groups is managed and stored in different authentication providers, including UID/GID and SID information, and user group membership information. OneFS can add multiple types of authentication provider, including:
- Active Directory (AD)
- Lightweight Directory Access Protocol (LDAP) servers
- NIS
- File provider
- Local provider
OneFS retrieves a user’s identity (UID/GID/SID) and group memberships from the above authentication providers. Assuming that we have a user named Joe, OneFS tries to resolve Joe’s UID/GID and group memberships from LDAP, NIS, file provider, and Local provider. Meanwhile, it also tries to resolve Joe’s SID and group memberships from AD, file provider, or local provider.
- If neither UID/GID nor SID can be found in any of the authentication providers, the user does not exist. User access may be denied or be mapped to the ‘nobody’ user, depending on your protocol.
- If only a UID/GID can be found or only a SID can be found, OneFS generates a fake UID or SID for the user.
It is not always the case that OneFS needs to resolve a user from username to UID/GID/SID. It is also possible that OneFS needs to resolve a user in reverse: that is, resolve a UID to its related username. This usually occurs when using NFSv3. When OneFS gets all UID/GID/SID information for a user, it will maintain the identity relationship in a local database, which records the UID <--> SID and GID <-->SID mapping, also known as the ID mapping function in OneFS.
Now, you should have an overall idea about how OneFS maintains the important UID/GID/SID information, and how to retrieve this information as needed.
Next, let’s see how OneFS can determine whether different usernames in different authentication types are actually the same real user. For example: how can we tell if the Joe in AD and the joe_f in LDAP is same guy or not? If they are the same, OneFS needs to ensure that they have the same access to the same file, even with different protocols.
That is the magic of the OneFS user mapping function. The default user mapping rule maps users together that have the same usernames in different authentication providers. For example, the Joe in AD and the Joe in LDAP will be considered the same user. You must create user mapping rules if a real user has different names in different authentication providers. The user mapping rule can have different operators, to provide more flexible management between different usernames in different authentication providers. The operators could be Append, Insert, Replace, Remove Groups, Join. See OneFS user mapping operators for more details. We just need to remember that the user mapping is just a function to determine if the user information in an authentication provider should be used when generating an access token.
Although it is easy to confuse user mapping with ID mapping, user mapping is the process of identifying users across authentication providers for the purpose of token generation. After the token is generated, the mappings of SID<-->UID are placed in the ID mapping database.
Finally, OneFS must choose an authoritative identity (that is, an On-Disk Identity) from the collected/generated UID/GID/SID for the user, which will be stored on disk and is used when the file is created or when ownership of file changes, impacting the file permissions.
In a single protocol environment, determining the On-Disk Identity is simple because Windows uses SIDs and Linux uses UIDs. However, in a multi-protocol environment, only one identity is stored, and the challenge is determining which one is stored. By default, the policy configured for on-disk identity is Native mode. Native mode is the best option for most environments. OneFS selects the real value between the SID and UID/GID. If both the SID and UID/GID are real values, OneFS selects UID/GID. Please note that this blog series is based on the default policy setting.
Now you should have an overall understanding of user mapping, ID mapping, and on-disk identity. These are the key concepts when understanding user access tokens and doing troubleshooting. Finally, let’s see what an access token contains.
You can view a user’s access token by using the command isi auth mapping token <username> in OneFS. Here is an example of Joe’s access token:
vonefs-aima-1# isi auth mapping token Joe User Name: Joe UID: 2001 SID: S-1-5-21-1137111906-3057660394-507681705-1002 On Disk: 2001 ZID: 1 Zone: System Privileges: - Primary Group Name: Market GID: 2003 SID: S-1-5-21-1137111906-3057660394-507681705-1006 On Disk: 2003 Supplemental Identities Name: Authenticated Users SID: S-1-5-11 Below
From the above output, we can see that an access token contains the following information:
- User’s username, UID, SID, and final on-disk identity
- Access zone ID and name
- OneFS RBAC privileges
- Primary group name, GID, SID, and final on-disk identity
- Supplemental group names, GID or SID.
Still, remember that we have a file created and owned by Joe in the previous blog? Here are the 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
The ls -le command here shows the user’s username only. And we already emphasized that the on-disk identity is always UID/GID or SID, so let’s use the ls -len command to show the on-disk identities. In the following output, we see that Joe’s on-disk identity is his UID 2001, and his GID 2003. When Joe wants to access the file, OneFS compares Joe’s access token with the file permissions below, finds that Joe’s UID is 2001 in his token, and grants him access to the file.
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
The above Joe is a OneFS local user from a local provider. Next, we will see what the access token looks like if a user’s SID is from AD and UID/GID is from LDAP.
Let’s assume that user John has an account named John_AD in AD, and also has an account named John_LDAP in LDAP server. This means that OneFS has to ensure that the two usernames have consistent access permissions on a file. To achieve that, we need to create a user mapping rule to join them together, so that the final access token will contain the SID information in AD and UID/GID information in LDAP. The access token for John_AD looks like this:
vonefs-aima-1# isi auth mapping token vlab\\John_AD User Name: VLAB\john_ad UID: 1000019 SID: S-1-5-21-2529895029-2434557131-462378659-1110 On Disk: S-1-5-21-2529895029-2434557131-462378659-1110 ZID: 1 Zone: System Privileges: - Primary Group Name: VLAB\domain users GID: 1000041 SID: S-1-5-21-2529895029-2434557131-462378659-513 On Disk: S-1-5-21-2529895029-2434557131-462378659-513 Supplemental Identities Name: Users GID: 1545 SID: S-1-5-32-545 Name: Authenticated Users SID: S-1-5-11 Name: John_LDAP UID: 19421 SID: S-1-22-1-19421 Name: ldap_users GID: 32084 SID: S-1-22-2-32084
Assume that a file that is owned and only accessible by John_LDAP has the file permissions shown in the following output. As the John_AD and John_LDAP is joined together with a user mapping rule, the John_LDAP identity (UID) is also in the John_AD access token, so John_AD can also access the file.
vonefs-aima-1# ls -le john_ldap.txt -rwx------ 1 John_LDAP ldap_users 19 Jun 15 07:36 john_ldap.txt OWNER: user:John_LDAP GROUP: group:ldap_users SYNTHETIC ACL 0: user:John_LDAP allow file_gen_read,file_gen_write,file_gen_execute,std_write_dac 1: group:ldap_users allow std_read_dac,std_synchronize,file_read_attr
You should now have an understanding of OneFS access tokens, and how they are used to determine a user’s authorized operation on data, through file permission checking.
In my next blog, we will see what will happen for different protocols when accessing OneFS data.
Resources
Author: Lieven Lin
OneFS Access Control Lists Overview
Thu, 18 Jan 2024 22:29:13 -0000
|Read Time: 0 minutes
As we know, when users access OneFS cluster data via different protocols, the final permission enforcement happens on the OneFS file system. In OneFS, this is achieved by the Access Control Lists (ACLs) implementation, which provides granular permission control on directories and files. In this article, we will look at the basics of OneFS ACLs.
OneFS ACL
OneFS provides a single namespace for multiprotocol access and 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 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 OneFS permissions management for networks that mix Windows and UNIX systems.
The OneFS ACL design is derived from Windows NTFS ACL. As such, many of its concept definitions and operations are similar to the Windows NTFS ACL, such as ACE permissions and inheritance.
OneFS synthetic ACL and real ACL
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:
- OneFS synthetic ACL: Under the default ACL policy, if no inheritable ACL entries exist on a parent directory – such as when a file or directory is created through a NFS or SSH session on OneFS within the parent directory – the directory will only contain POSIX mode bits permission. OneFS uses the internal representation to generate a OneFS synthetic ACL, which is an in-memory structure that approximates the POSIX mode bits of a file or directory for an SMB or NFSv4 client.
- OneFS real ACL: Under the default ACL policy, when a file or directory is created through SMB or when the synthetic ACL of a file or directory is modified through an NFSv4 or SMB client, the OneFS real ACL is initialized and stored on disk. The OneFS real ACL can also be initialized using the OneFS enhanced chmod command tool with the +a, -a, or =a option to modify the ACL.
OneFS access control entries
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:
- Identity name: The name of a user or group
- ACE type: The type of the ACE (allow or deny)
- ACE permissions and inheritance flags: A list of permissions and inheritance flags separated with commas
OneFS ACE permissions
Similar to the Windows permission level, OneFS divides permissions into the following three types:
- Standard ACE permissions: These apply to any object in the file system
- Generic ACE permissions: These map to a bundle of specific permissions
- Constant ACE permissions: These are specific permissions for file-system objects
The standard ACE permissions that can appear for a file-system object are shown in the following table:
ACE permission | Applies to | Description |
std_delete | Directory or file | The right to delete the object |
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 the following table:
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 the following table:
ACE permission | 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 | List entries |
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 |
OneFS ACL inheritance
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 are the same as Windows ACL inheritance and will feel familiar to someone versed in Windows NTFS ACL inheritance. The following table shows the ACE inheritance flags defined in OneFS:
ACE inheritance flag | Set on directory or file | Description |
object_inherit | 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 |
inherit_only | 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 |
Author: Lieven Lin