In VAST Cluster 3.0.1, a new mechanism was introduced for exposing directories over file sharing protocols. The new mechanism is called a view. Views can be configured to expose a directory over one or more file sharing protocols. In VAST Cluster these protocols are limited to NFS and SMB. Views replace exports in previous versions.
S3, also a supported protocol, is exposed using a different mechanism. For information about working with S3, see Using S3 Storage.
Client access to views is controlled differently depending on the protocol used to access the view:
-
SMB clients: SMB shares are supported with the requirement that the cluster is joined to an Active Directory service. SMB users are authenticated via Kerberos according to their user entries on the Active Directory server.
-
NFS clients: Access to NFS exports is controlled by host. You can configure which hosts can access which views and what types of access to allow to which hosts. This access control is done through the view policy which is specified in the view configuration. It enables you to specify which hosts have read/write or read only access to the view, and to apply root squash policies. Access to the trash folder feature for rapid file deletion is also managed this way. Hosts can be specified using their IPs. If you're using NIS, you can use netgroups to specify hosts. (NIS is not supported for multiprotocol access.)
VAST Cluster file objects are protected internally by access control lists (ACLs), which list access control entries (ACEs) defining which types of access (read, write, execute/search) are granted or denied to the file object owner, to specified users, to the file object owner's primary group, to specified user groups, and to other users.
When an NFS client process requests read, write or execute/search access to a file object, an VAST Cluster performs an access check to determine whether access to the object should be granted.
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.
If SMB access to the cluster is desired in addition to NFS access, either through multiprotocol access to the same views or to separate views, then an Active Directory server must be used as the auth provider. The connection must be configured as described in Joining Active Directory. This includes joining the cluster to the Active Directory domain as a machine account to enable SMB user authentication, and also configuring LDAP connectivity to the Active Directory server.
If SMB access is not needed, the auth provider can be either:
-
An LDAP server, including but not limited to Active Directory, configured per Connecting to an LDAP Server
OR
For NFS-exposed views, the options are:
-
Disable auth provider in the view policy. In this case, the incoming client process is indeed trusted for the user's GIDs. This option is not supported for multiprotocol views.
-
Enable auth provider in the view policy. In this case, 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, Active Directory 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'. If the view is multiprotocol (exposed to SMB as well as NFS), auth provider must be enabled and an Active Directory server must be joined.
Note
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).
Note
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.
Enable Return open permissions in a view policy via the VAST CLI (not using the VAST Web UI). See commands viewpolicy create and viewpolicy modify.
SMB shares are supported only with Active Directory. Users are authorized to access files and directories according to their user and group attributes on the Active Directory server. Users are granted the combination of permissions from the file object's ACEs that are granted to the user, or any group the user belongs to.
NFS and SMB clients manage permissions for users and groups to access files and directories through different mechanisms: NFS clients use Posix ACLs and permission mode bits, while SMB clients use NTFS ACLs.
When you expose a view to both NFS and SMB clients, you can choose between two security flavors to determine how permissions are managed. Each security flavor allows only one protocol to set permissions on files and directories:
|
Security Flavor |
Behavior |
|---|---|
|
NFS |
NFS clients may set and modify file and directory permissions. Attempts by SMB clients to assign or modify file and directory permissions fail. A file or directory created by an SMB client receives initial permissions from the permission mode bits defined in the view policy. However, if the Posix ACL setting is enabled in the view policy and there is a default POSIX ACL set on the parent directory, the permissions are taken from the parent directory instead of from the mode bits defined in the view policy. |
|
SMB |
SMB clients may set and modify file and directory permissions. Attempts by NFS clients to set permission bits for files and directories are ignored. Files and directories created by NFS clients inherit their initial permissions from the parent directory based on standard NTFS ACL inheritance rules. |
When a view has NFS security flavor, file and directory permissions on SMB clients are transposed and inherited according to the mapping in the following table.
When a view has SMB security flavor, operations are allowed and denied to all clients according to the more granular specific SMB permissions. When viewing the permission bits from an NFS client, each permission bit is shown if any (but not necessarily all) of its equivalent SMB permissions are granted on the file or directory.
|
Object type |
NFS Permission bit |
Equivalent SMB permissions |
|---|---|---|
|
File |
r |
FILE_READ_DATA + FILE_READ_EA + FILE_READ_ATTRIBUTES + SYNCHRONIZE + READ_CONTROL |
|
|
w |
FILE_WRITE_DATA + FILE_APPEND_DATA + FILE_WRITE_EA + FILE_WRITE_ATTRIBUTES + SYNCHRONIZE + READ_CONTROL |
|
|
x |
FILE_EXECUTE + SYNCHRONIZE + READ_CONTROL |
|
Directory |
r |
FILE_LIST_DIRECTORY + FILE_READ_EA + FILE_READ_ATTRIBUTES + SYNCHRONIZE + READ_CONTROL |
|
|
w |
FILE_ADD_FILE + FILE_ADD_SUBDIRECTORY + FILE_WRITE_EA + FILE_DELETE_CHILD + FILE_WRITE_ATTRIBUTES + SYNCHRONIZE + READ_CONTROL |
|
|
x |
FILE_TRAVERSE + SYNCHRONIZE + READ_CONTROL |
It is possible to create different views on paths that are nested under each other. For example, you can have a view on the path /a/b and another view on the path /a/b/c. Each view can use a different view policy.
This is useful, for example, if you want to give a larger set of NFS client hosts read/write access to the higher level directory while giving a subset of NFS client hosts read/write access to a deeper directory.
However, it is not recommended to set security settings, including security flavor and other multiprotocol behavior settings (such as path length limit or allowed characters which are options you can set in multiprotocol view policies), on a child directory's view that are different to the security settings of its parent directory's view, since this could result in unpredictable behavior with permission authorization.
For multiprotocol views, the VAST Cluster user database (UDB) uses the Active Directory server to map NFS and SMB user and group attributes in order to ensure that users are authorized with the correct file and directory permissions independent of the client protocol used to access a view.
A user may be discovered by the cluster as the file owner when creating a file on the cluster or when referenced as a user in the ACL of a file written by another user of a file, or when a group the user belongs to is referenced in the ACL of a file written by another user. NFS users are identified using the uid attribute while SMB users are identified using a user SID. NFS groups are identified using gid. SMB groups have a sid.
When the cluster discovers a new user via either protocol, a new user entry is created on the cluster's user database (UDB). The cluster's UDB queries the Active Directory server in order to perform an identity match between the discovered UID and the same user's user SID or between the discovered user SID and the same user's uid. The UDB also queries AD for group memberships and matches those across the two protocols. The new user entry contains the user's UID, user SID and unique group IDs for the user's primary and auxiliary groups.
To ensure proper attribute mapping, users must be defined with the requisite NFS and SMB user and group membership attributes on the AD server in accordance to the RFC2307 specification. The SMB attributes are mandatory in Active Directory user accounts. However, the NFS attributes are optional in Active Directory and yet must be present in order for multiprotocol access to work correctly:
-
The NFS UID value should be contained in the uidNumber attribute of each user account. This is the numeric value identifying an NFS user.
-
The user's leading or primary group ID should be contained in the gidNumber attribute of each user account. This is the group that a file has as the owner-group when the user creates a file on an NFS client (provided NFS security flavor is selected and therefore the client can set permission bits).
-
Auxiliary or secondary groups. These can be marked either by a memberUid entry in each group that contains the user or by a memberOf entry in the user entry for each group that contains the user.
Note that local users (see Adding Local Users) are not supported by multi-protocol views. All users must be defined on the Active Directory server in order to be able to access any files or directories in the view.
Comments
0 comments
Article is closed for comments.