For VAST Cluster 3.0.1, see File Permissions Authorization for NFS Exports.
The access check looks at the ACEs in order of owner, named users, owning or named groups, others, and selects the entry that most closely matches the requesting process. Then the access check determines if the matching entry contains sufficient permissions to allow the requested type of access.
When the access check looks for a match between the user's UID and the owning or named users in the ACL entries, the UID from the incoming client request is always used.
However, when the access check looks for a match between the user's GIDs and the owning or named groups, the incoming client request is not necessarily trusted for the user's GIDs. Group permissions can be enforced by the user database, which can be updated from a configured auth provider.
The auth provider can be either:
The auth provider function can be enabled or disabled in each export, and that is controlled by the export policy:
If auth provider is disabled in the export policy, the incoming client process is indeed trusted for the user's GIDs.
If auth provider is enabled in the view policy, the access check will retrieve the user's GIDs from the cluster's user database, using the client process UID as the key. If the cluster is configured to connect to an LDAP server or NIS, the user entries are periodically updated from the LDAP server or the NIS users map, with the exception of user entries defined as 'local'.
By default, VAST Cluster supports the traditional POSIX file system object permission mode bits, (minimal ACL mode) in which each file has three ACL entries defining the permissions for the owner, owning group, and others, respectively. You can optionally enable support for extended ACLs by enabling the POSIX ACL setting in the relevant export(s).
Microsoft NFS Client running on Windows does an access check before it executes requests. It performs the check using the UID and the primary GID of the user without taking into account the user's secondary GIDs. Requests are only executed by the client if this check passes. If the check fails, the user's requests are not executed and therefore VAST Cluster doesn't do the access check described above. This means that some permissions may not be honored as they should be, such as those based on secondary groups.
To overcome this issue, you can enable a setting called Return open permissions in the view policy. This setting sets the NFS server to unilaterally return open permission (777) for all files and directories when responding to client side access checks. The open permission response will prevent the client side check from failing. VAST Cluster will do the proper access check when the request is executed.
This solution is not suitable for shared Windows systems, since the following scenario could occur: A user could request access to a file while it is being used by another user and is cached in the Windows memory. The WIndows runtime process, seeing that the file is in the cache and has open permission from VAST Cluster , will incorrectly authorize the second user's access.