Configuration of NFS exports, SMB shares and S3 buckets is done through the configuration of views. A view creates an Element Store path and exposes it to one or more client protocols.
A view specifies a path in the Element Store, the protocols that are allowed to store and access data at that path, the respective methods for exposing the path to each enabled protocol, and a view policy.
A view policy defines security settings that further control access to the data, such as restricting types of access by host IP or choosing a security 'flavor' which determines cross protocol behavior for handling permissions for users and groups to access files or objects.
See the following sections for more information about views and view policies:
Each file sharing and object storage protocol uses its own system for managing user and group permissions to files and directories: NFS uses permission mode bits with the option of POSIX ACL extensions in NFSv3 and NFSv4 ACLs in NFSv4.1. SMB uses NTFS Access Control Lists (ACLs). S3 uses Identity Policies and S3 ACLs. The permission systems differ in terms of how granular the permissions are and the algorithm used to perform access checks. The protocols also require differing permissions for performing similar operations or operations that achieve the same result through different mechanisms.
In order to enable multiple protocols to access the same files, ensure that permissions are authorized for users consistently across protocols, and to give you control over which protocols are able to set permissions on files and directories, VAST Cluster enables you to choose from several modes of permission behavior, called security flavors.
The security flavor is set in every view policy. It determines which protocol's permission checking algorithm is used, which protocols are allowed to set permissions on files and directories and how initial permissions are set on new files and directories.
NFS security flavor treats NFS as a native protocol and treats the other protocols as non-native protocols.
With NFS security flavor:
-
Permissions checking follows the NFS permission checking algorithm where permission checking is done in an ordered mode selecting the first grantee permission.
-
NFSv3 and NFSv4.1 clients may set and modify file and directory permissions using Unix permission mode bits.
-
NFSv4.1 clients may not set NFSv4.1 ACLs.
-
Attempts by SMB clients to set or modify file and directory permissions fail.
-
S3 requests to set or modify bucket and object ACLs are silently ignored.
-
S3 requests are first checked against identity policies before being checked according to Unix permission mode bits. In other words, identity policies are effective for requests made by S3. However, ACL modifications, even if allowed by an identity policy, are ignored.
-
Default permission mode bits are defined in the view policy. The default permission mode bits are applied as initial permissions to any files/objects and directories/buckets that are created by SMB or S3 clients.
However, if the Posix ACL setting is enabled in the view policy and there is a default POSIX ACL set by NFSv3 on the parent directory, the permissions are taken from the parent directory instead of from the mode bits defined in the view policy.
SMB clients receive the following permissions for each permission mode bit set by the view policy or by an NFS client:
|
Object type |
Permission Mode 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 |
When working in NFS flavor, the following aspects of NFS permission checking rules impact the permissions required for some RPCs:
-
In NFS, in order to perform an operation on a file or directory, the user needs to have traverse permission on all directories along the path to the file.
-
In NFS flavor, in order to upload an object, you will need write permission on the parent directory of the file.
Following are some examples of where these differences apply.
-
User A creates intermediate directory a/ under the view directory (from NFS) and creates a file b under the directory.
-
User A grants user B write permission on a/ and read permission on b.
-
User B is unable to copy a/b from S3. The attempt fails because user B was not granted traverse permission on 'a/'
SMB security flavor treats SMB as a native protocol and NFS as a non-native protocol.
With SMB security flavor:
-
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 SMB security flavor, operations are allowed and denied to all clients according to SMB permissions which are more specific and granular than NFS permissions. When viewing the permission bits of a file or directory 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.
-
S3 is not supported.
Mixed Last Wins flavor allows file and directory permissions to be set and modified by all clients. This includes support for NFSv4.1 clients to set NFSv4.1 ACLs.
As far as possible, this flavor is designed such that whenever a user changes permissions via a given protocol, the permission change that is applied in vast permissions is as the user intended.
The following are details of how specific scenarios are handled with the Mixed Last Wins security flavor.
In SMB, full control on an object includes permission to delete the object. In NFS, object deletion requires a ‘w' permission bit on the object's parent directory. This discrepancy is handled such that a 'w’ NFS permission on a directory maps to “Add file” + “Add sub-directory” + “Delete child” permissions for SMB clients.
Additionally, full control in SMB allows the grantee to change the permissions of an object. In NFS, only the owning user can change the permissions of the object. Since the SMB permission full control could be granted to any and all users rather than just the user who created the file, this is a discrepancy between the protocols, which is handled as follows:
NFS permission mode bits ‘777’ are mapped to all permissions except for the permissions to change the owner or the permissions of the file/directory. An NFS user cannot allow another user to change the permissions of a file from any protocol, while an SMB user can grant that permission to specific or all users, who can then change the permissions from any protocol.
When a file is created via NFS, the requested mode bits are applied to the file. (This really means that VAST ACEs which correspond to those mode bits are applied. The same principle applies throughout all of these scenario descriptions.)
When a file is created via SMB, ACEs are inherited from the parent directory. If the parent directory has no inheritable ACEs, a built-in default ACL is used. The default gives the owner “FULL CONTROL” as defined in Windows.
If a directory is created by an SMB user and then an NFS user creates a file under that directory, the user always attempts to set mode bits on the file. Even if the SMB directory has some inheritable ACEs, the mode bits set by the NFS user are applied to the file, which may override those inheritable ACEs.
For example, if a directory is created via SMB with an inheritable ACE granting ‘full control’ to ‘Everyone’ and then a file is created inside it via NFS with permissions 0x700, the result is that the file has permissions only for the owner (and for root, if no root squash).
A sub-directory created by NFS would normally have no inheritable ACEs, while a file created via SMB would only receive ACEs by inheriting them from the parent directory. Therefore, in Mixed Last Wins flavor, when a sub-directory is created via NFS, all inheritable ACEs are copied from the parent directory to the newly created sub-directory as inherit only, meaning that the ACEs will be inherited by objects created in the sub-directory.
Example: a directory is created via SMB with an inheritable ACE granting full control to Everyone. A sub-directory is created inside this directory via NFS. A file is then created via SMB inside this sub-directory. The file is accessible to all users from all protocols since Mixed Last Wins behavior caused the ACE that grants full control to Everyone to be copied to the sub-directory from the parent directory when the sub-directory was created with inherit only mode which made the ACE inheritable by any file created in the sub-directory.
In NFS, in order to access a file or sub-directory, the user must have ‘x' permissions on all the sub-directories along the path. In contrast, SMB does not require this permission in order for a user to have permission to access an object via its full path. In Mixed Last WIns flavor, VAST Cluster requires the user to have traverse permissions in order to access such an object.
S3 native security flavor treats S3 as a native protocol and NFS as a non native protocol.
With S3 flavor:
-
Identity policies, which are created and managed via VMS, are the primary access management tool.
-
The S3 permission checking algorithm is used, in which:
-
If an identity policy that is attached to the user or to one of the user's groups denies the requested action, the request is denied.
-
Otherwise, if an identity policy attached to the user or to one of the user's groups allows the requested action, the request is allowed.
-
Otherwise, permissions are checked according to S3 ACLs. Multiple ACEs per user are supported and they are aggregated to allow the most permissive mode.
-
-
Permission to traverse directories along the path to a file is not required in order to do an operation on the file from any enabled protocol.
-
Some NFSv3 and NFSv4.1 requests are mapped to S3 actions and can therefore be allowed or denied by identity policies. For the permission mapping, see Mapping of NFSv3 Requests with S3 Actions and S3 Permissions Required for NFSv4.1 Actions.
-
NFSv3 and NFSv4.1 requests that do not map to S3 actions are authorized according to S3 ACLs.
-
Attempts by NFSv3 and NFSv4.1 users to set permissions on files and directories are ignored.
-
New buckets receive a default initial S3 bucket ACL, which gives the bucket owner FullControl. New objects receive a default initial S3 object ACL, which gives the owner FullControl. These ACLs are subject to be overridden by identity policies as described above.
-
S3 users can modify ACLs on buckets and objects via S3, provided they have permission to do so.
-
SMB is not supported.
In S3 Native flavor, identity policies impact the following NFSv3 RPCs as described in the table. Other NFSv3 RPCs are authorized according to ACLs.
|
NFSv3 RPC |
Identity Policy Permission Mapping |
|---|---|
|
CREATE |
PutObject |
|
GETACL |
Permission is denied only if a GetObjectAcl and/or HeadObject action with a “deny” effect is found in a policy. |
|
GETATTR |
Permission is denied only if a GetObjectAcl and/or HeadObject action with a “deny” effect is found in a policy. |
|
READ |
GetObject |
|
READDIR |
ListObjects or ListObjectsV2 |
|
READDIRPLUS |
ListObjects or ListObjectsV2 |
|
REMOVE |
DeleteObject |
|
RENAME |
PutObject and DeleteObject |
|
SETACL |
Not allowed via NFS in S3 Native Flavor. |
|
SETATTR |
Not allowed via NFS in S3 Native Flavor. |
|
WRITE |
PutObject |
In S3 Native flavor, identity policies impact the following NFSv3 RPCs as described in the table. Other NFSv3 RPCs are authorized according to ACLs.
|
NFSv4.1 RPC |
Identity Policy Permission Mapping |
|---|---|
|
CREATE |
PutObject |
|
OPEN |
PutObject and/or GetObject (based on requested access mask) |
|
GETATTR |
Permission is denied only if a GetObjectAcl and/or HeadObject action with a “deny” effect is found in a policy. |
|
READ |
GetObject |
|
READDIR |
ListObjects or ListObjectsV2 |
|
REMOVE |
DeleteObject |
|
RENAME |
PutObject and DeleteObject |
|
SETATTR |
The following attributes are supported and can be modified by NFS in S3 Native flavor with the following permissions:
|
|
WRITE |
N/A (because access check decisions are taken during the execution of the OPEN RPC) |
|
CLOSE |
Always allowed |
|
OPEN_DOWNGRADE |
No permissions required as they were already fulfilled in the OPEN RPC |
In S3 Native flavor, users need to work with an awareness of two main ways that working with S3 style permissions differs from the usual native NFS behavior:
-
The need for relevant permission to be granted via identity policies or S3 ACLs for a given operation. The default ACL on a new bucket or object gives full control to the owner. Other users have no permission unless it is granted by identity policies or until ACLs are modified by S3 requests to grant permissions to additional users.
-
The lack of a concept or requirement for traverse permission on all directories along the path to a given file or directory in order to access that file or directory.
Following are some examples of where these differences apply.
-
User 'A' uploads an object to a view via an S3 command.
-
User 'B' attempts to read the uploaded object as a file via NFS.
-
The read fails since user 'B' is not the owner of the object and noone other than the owner has read permission for the object by default.
A suggested solution for allowing read attempts like this one is to include permission for the GetObject S3 action in an identity policy and attach that identity policy to users or groups.
-
User A and User B are both granted write permission on a bucket.
-
User A creates an intermediate directory via NFS under the bucket directory.
No permissions on the directory are granted to user B.
-
User B is able to create a file inside the intermediate directory.
This is because there is no concept of or requirement for traverse permission along the path with S3 permission checking.
The security flavor options available depend on which protocols are enabled on the view:
Table 1. Protocol and Security Flavor Support
|
Protocol |
NFS Flavor Support |
SMB Flavor Support |
Mixed Last Wins Flavor Support |
S3 Native Flavor Support |
|---|---|---|---|---|
|
NFSv3 |
Yes |
Yes |
Yes |
Yes |
|
NFSv4.1 |
Yes (without NFSv4 ACLs) |
No |
Yes |
Yes (without NFSv4 ACLs) |
|
SMB |
Yes |
Yes |
Yes |
No |
|
S3 |
Yes |
No |
No |
Yes |
The algorithm used to check if a user has the requested permission to access a file or directory is different depending on the security flavor:
-
With NFS flavor, the NFS permissions checking algorithm is used, in which ACL entries are looked at in order of owner, named users, (owning or named) groups, others. Only the permissions of the first matching single entry determine if access is granted.
-
With SMB flavor, the SMB permissions checking algorithm is used, in which permissions granted to the user are the combination of all permissions in matching ACEs in the object's ACL.
-
With S3 Native flavor, in accordance with S3 protocol:
-
Access checking begins with any and all identity policies that are attached to the user or to any group to which the user belongs. Policy statements that deny permission are checked first. If the requested action is denied by an identity policy, the request is denied.
-
If the requested action is not denied by an identity policy, and it is allowed by an identity policy, then the request is allowed.
-
If the requested action is neither denied nor allowed by an identity policy, then ACLs are checked. Accessing checking on ACLs is done in an unordered mode, in which ACEs are scanned until the most permissive ACE is found and that is the ACE that is applied.
-
Access checking for permission granted by ACL to read an object is done only on the object itself and not on directories along the path. So, e.g. the permissions of the directory in which the file resides is ignored in permission checks.
-
Write permissions for NFS clients are checked against the bucket's ACL, in accordance with the S3 protocol where objects are not modified but replaced.
-
-
With Mixed Last Wins flavor, the algorithm used is similar to that of SMB flavor with the addition that in order to access an object, the user must have traverse permission on all directories leading from the share/export’s top down to the object.
|
Flavor |
Allows Permission Setting via NFS? |
Allows Permission Setting via SMB? |
Allows Permission Setting via S3? |
Requires administrator to define initial object permissions for a non favored protocol? |
Permission Checking Algorithm |
Traverse permission required for access to an object? |
|---|---|---|---|---|---|---|
|
NFS |
Yes |
No |
No |
Yes. In the view policy, the administrator defines permission bits to be applied to new files and directories created via SMB and S3. |
NFS, in which ACL entries are looked at in order of owner, named users, (owning or named) groups, others. Only the permissions of the first matching single entry determine if access is granted. |
Yes |
|
SMB |
No |
Yes |
No |
No. Files and directories created by NFS clients inherit initial permissions from the parent directory based on standard NTFS ACL inheritance rules. |
SMB, in which permissions granted to the user are the combination of all permissions in matching ACEs in the object's ACL. |
No |
|
Mixed Last Wins |
Yes |
Yes |
Yes |
No, since permissions can be set via both protocols. |
Like SMB, but with the addition that in order to access an object, the user must have traverse permission on all directories leading from the share/export’s top down to the object. |
Yes |
|
S3 Native |
No |
No |
Yes |
No. Files and directories created by NFSv3 and NFSv4.1 clients have an ACE that gives FULL CONTROL to the file (object) owner. |
S3, in which ACEs are scanned until the most permissive mode is found. |
No |
The view policy includes host based access rules which you can use to restrict which NFS client hosts can access views (those that use the policy you are configuring) and specify which type of access to allow from each host IP.
The default configuration gives all hosts read write access and root squashing. The root squash policy is relevant only for NFSv3 clients.
The rules are:
-
Read Write.
By default, all hosts have read write access. You have the option to restrict access by specifying sets of hosts with each type of access. Any hosts that are not specified for either read write or read only access cannot access the view.
-
Read Only
-
No Squash. All operations are supported. Use this option if you trust the root user not to perform operations that will corrupt data.
This option is not relevant for clients using NFSv4.1 with Kerberos, since Active Directory does not include the 'root' user principal by default and since the handling of credentials for the user with UID 0 depends on configuration of the rpc.gssd service.
-
Root Squash. The root user is mapped to nobody for all file and folder management operations on the export. This enables you to prevent the strongest super user from corrupting all user data on the VAST Cluster.
This option is not relevant for clients using NFSv4.1 with Kerberos, since Active Directory does not include the 'root' user principal by default and since the handling of credentials for the user with UID 0 depends on configuration of the rpc.gssd service.
-
All Squash. All client users are mapped to nobody for all file and folder management operations on the export.
-
Trash Access. This option appears only if the Trash folder setting is enabled on the Cluster settings page
This access type is applicable for NFSv3 clients only. The Trash folder feature is not supported for NFSv4.1 clients.
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.
-
S3 bucket views should not have views nested under them.
When you enable the SMB protocol on a view together with NFSv4.1 and/or NFSv3, non-simultaneous access to any files in the view from all enabled protocols is fully supported by default.
If simultaneous access to files from SMB and from an NFS protocol is likely to occur in your environment, read about enabling NFS interoperability on the view, which adds further support to address differences in file locking behavior between the protocols.
Comments
0 comments
Article is closed for comments.