Traditionally, 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..
SMB uses NTFS Access Control Lists (ACLs).
S3 uses identity policies, bucket 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.
Security Flavors
NFS Security Flavor
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.
NFS requests are checked only against NFS permission mode bits.
NFSv3 and NFSv4 clients may set and modify file and directory permissions using Unix permission mode bits.
NFSv4 clients may not set NFSv4 ACLs.
Attempts by SMB clients to set or modify file and directory permissions fail.
S3 requests are checked against NFS permission mode bits.
S3 requests to set or modify bucket and object ACLs are silently ignored.
S3 requests are not checked against identity policies or bucket policies.
Files/objects and directories/buckets created by protocols other than NFS on a view controlled with the NFS security flavor get their permission mode bits as follows, based on view policy settings:
From the view policy where they have been set manually, or
From the parent directory ACL.
Note
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 taking them from the mode bits defined in the view policy.
SMB Permissions in NFS Security Flavor
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 |
Examples of Permissions Behavior for S3 RPCs in NFS Flavor
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.
Example: Traverse Permission Required for Write
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/'.
Example: Full Path Traversal Permission Required for Object Read
An S3 user fails to read object 'a/b/c'.
'a/b/' is a directory created via NFS with mode bits 0.
SMB Security Flavor
SMB security flavor treats SMB as a native protocol and other protocols (NFSv3, NFSv4, S3) as non-native protocols.
With SMB security flavor:
SMB clients may set and modify file and directory permissions. Attempts by non-SMB clients to set permissions for files and directories are ignored.
Files and directories created by non-SMB clients inherit their initial permissions from the parent directory based on standard NTFS ACL inheritance rules.
When a view has SMB security flavor, operations requested by any client are authorized based on SMB permissions.
SMB permissions 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.
When an S3 client attempts to access a view controlled by the SMB security flavor:
Only permissions for the requested resource are taken into account.
Permissions on parent directories are ignored.
S3 clients are denied the ability to set or modify ACLs.
Identity policies and bucket policies are ignored.
Mixed Last Wins Security Flavor
Mixed Last Wins flavor allows file and directory permissions to be set and modified by all clients (NFS, SMB, S3). This includes support for NFSv4 clients to set NFSv4 ACLs.
As far as possible, this flavor is designed so that whenever a user changes permissions via a given protocol, the permission change that is applied in VAST permissions is as the user intended.
When an S3 client attempts to access a view controlled by the Mixed Last Wins security flavor:
Permissions for the resource requested and for all parent directories in the path are taken into account.
S3 clients are allowed to set and modify ACLs.
Identity policies and bucket policies are ignored.
Mixed Last Wins Access Flavors
When using Mixed Last Wins, you can control which protocols can set file permissions using the Access Flavor option, which can be set for a view policy via the VAST CLI.
Note
NFSv3 and S3 protocols are unaffected by the access flavor setting.
Choose one of the following access flavors:
ALL (default). No protocol is blocked from setting file permissions.
NFS4. Allows NFSv4 to set file permissions, and blocks SMB from setting file permissions. With this access flavor, an attempt by an SMB client to set the ACL, owner, or owner group will silently fail.
SMB. Allows SMB to set file permissions, and blocks NFSv4 from setting file permissions. With this access flavor, the outcome of NFSv4 permission-setting attempts is as follows:
An attempt by an NFSv4 user to create files and directories succeeds. Any implicitly provided mode bits, owner and owner group are silently ignored. The mode bits are inherited from the parent folder. The owner and owner group are that of the requesting user regardless of any specified owner or owner group.
An attempt by an NFSv4 user to set mode, ACL, owner or owner group silently fails.
Note
Linux super user cannot bypass this blocking.
With the SMB access flavor, the user is not required to have traverse permissions on all directories leading from the share/export’s top down to the object being accessed.
Caution
Changing the access flavor when already in effect on a view that is being used by clients could lead to unexpected behavior and is not advised.
Specific scenarios with the Mixed Last Wins Security Flavor
The following are details of how specific scenarios are handled with the Mixed Last Wins security flavor.
Discrepancies between 'full control' SMB permission and '777' NFS permission bits
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 which 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, which can then change the permissions from any protocol.
File Creation
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.
Creating files via NFS under a directory with SMB permissions
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).
Creating files via SMB under a directory with NFS permissions
A subdirectory 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 subdirectory is created via NFS, all inheritable ACEs are copied from the parent directory to the newly created subdirectory as inherit only, meaning that the ACEs will be inherited by objects created in the subdirectory.
Example: a directory is created via SMB with an inheritable ACE granting full control to Everyone. A subdirectory is created inside this directory via NFS. A file is then created via SMB inside this subdirectory. 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 subdirectory from the parent directory when the subdirectory was created with inherit only mode which made the ACE inheritable by any file created in the subdirectory.
Accessing Subdirectories via SMB
In NFS, in order to access a file or subdirectory, the user must have ‘x' permissions on all the subdirectories along the path. This is called traverse permissions. 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 does not require the user to have traverse permissions in order to access such an object.
S3 Native Security Flavor
S3 Native security flavor treats S3 as a native protocol, while NFS and SMB are considered non-native protocols.
With S3 Native security flavor:
Identity and bucket policies are the primary access management tool.
The S3 permission checking algorithm is used, in which:
If an identity or bucket policy denies the requested action, the request is denied. For NFS and SMB requests, this applies only to request types that are mapped to S3 user permissions.
Otherwise, if an identity or bucket policy allows the requested action, the request is allowed. For NFS and SMB requests, this applies only to request types that are mapped to S3 user permissions.
Otherwise, permissions are checked according to S3 ACLs and the VMS-granted user permissions. Multiple ACEs per user are supported and they are aggregated to allow the most permissive mode.
Note
The above flow may be altered depending on the ACLs enabled or ACLs disabled mode set for the view. See S3 Object Ownership for details.
There is a view policy setting that controls whether NFS and SMB clients are able to list bucket views and their subdirectories based on individual object permissions or based on identity policies.
Some NFS and SMB requests are mapped to S3 actions and can therefore be allowed or denied by identity or bucket policies. For the permission mapping,
NFS and SMB requests that are not mapped to S3 actions, are authorized according to S3 ACLs.
Attempts by NFS and SMB users to set permissions on files and directories are silently 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 and bucket policies as described above.
S3 users can modify ACLs on buckets and objects via S3, provided they have permission to do so.
SMB privileged users or groups are not honored.
Versioned objects are only accessible by SMB and NFS clients as read-only.
Mapping of NFSv3 Requests with S3 Actions
In S3 Native flavor, identity and bucket policies impact the following NFSv3 RPCs as described in the table. Other NFSv3 RPCs are authorized according to ACLs.
NFSv3 RPC | Identity/Bucket Policy Permission Mapping |
|---|---|
COMMIT | PutObject |
CREATE | PutObject |
FSINFO | HeadBucket |
FSSTAT | HeadObject |
GETACL | Access is denied only if a GetObjectAcl and/or HeadObject action with a “deny” effect is found in a policy. |
GETATTR | Access is denied only if a GetObjectAcl and/or HeadObject action with a “deny” effect is found in a policy. |
LINK | DeleteObject, PutObject |
LOOKUP | HeadObject |
MKDIR | PutObject |
MKNOD | PutObject |
PATHCONF | HeadBucket |
READ | GetObject |
READDIR | ListObjects or ListObjectsV2 |
READDIRPLUS | ListObjects or ListObjectsV2 |
READLINK | GetObject |
REMOVE | DeleteObject |
RENAME | PutObject and DeleteObject |
RMDIR | DeleteObject |
SETACL | PutObjectAcl |
SETATTR | Not allowed via NFS in S3 Native Flavor. |
SYMLINK | PutObject |
WRITE | PutObject |
S3 Permissions Required for NFSv4 Actions
In S3 Native flavor, identity and bucket policies impact the following NFSv4 RPCs as described in the table. Other NFSv4 RPCs are authorized according to ACLs.
NFSv4 RPC | Identity/Bucket Policy Permission Mapping |
|---|---|
CREATE | PutObject |
GETATTR | Access is denied only if a GetObjectAcl and/or HeadObject action with a “deny” effect is found in a policy. |
OPEN | PutObject and/or GetObject (based on requested access mask) |
LINK | PutObject |
LOOKUP | HeadObject |
LOOKUPP | HeadObject |
READLINK | GetObject |
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 |
Mapping of SMB Requests with S3 Actions
In S3 Native flavor, identity and bucket policies impact the following SMB RPCs. Other SMB RPCs are authorized according to ACLs.
SMB RPC | Identity/Bucket Policy Permission Mapping |
|---|---|
SMB2_CREATE | Per access mask encoding. See below, File/Pipe/Printer Access Mask and Directory Access Mask |
SMB2_QUERY_INFO SMB2_CLOSE SMB2_FLUSH SMB2_READ SMB2_WRITE SMB2_LOCK SMB2_IOCTL SMB2_ECHO SMB2_CHANGE_NOTIFY SMB2_OPLOCK_BREAK | According to SMB2_CREATE result |
SMB2_SET_INFO |
|
Following are the mappings for SMB2_CREATE requests with a file/pipe/printer access mask.
File/Pipe/Printer Access Mask | Identity/Bucket Policy Permission Mapping |
|---|---|
FILE_APPEND_DATA | PutObject |
FILE_DELETE_CHILD | DeleteObject |
DELETE | DeleteObject |
FILE_EXECUTE | GetObject |
FILE_READ_ATTRIBUTES | HeadObject and GetObjectAcl |
FILE_READ_DATA | GetObject |
FILE_READ_EA | HeadObject and GetObjectAcl |
FILE_WRITE_ATTRIBUTES | PutObject |
FILE_WRITE_DATA | PutObject |
FILE_WRITE_EA | PutObject |
READ_CONTROL | HeadObject and GetObjectAcl |
SYNCHRONIZE | Access is granted |
WRITE_DAC | Access is denied |
WRITE_OWNER | Access is denied |
Following are the mappings for SMB2_CREATE requests with a directory access mask.
Directory Access Mask | Identity/Bucket Policy Permission Mapping |
|---|---|
FILE_ADD_FILE | PutObject |
FILE_ADD_SUBDIRECTORY | PutObject |
FILE_DELETE_CHILD | DeleteObject |
DELETE | DeleteObject |
FILE_LIST_DIRECTORY | ListBucket |
FILE_READ_ATTRIBUTES | HeadObject and GetObjectAcl |
FILE_READ_EA | HeadObject and GetObjectAcl |
FILE_TRAVERSE | HeadObject |
FILE_WRITE_ATTRIBUTES | PutObject |
FILE_WRITE_EA | PutObject |
READ_CONTROL | HeadObject and GetObjectAcl |
SYNCHRONIZE | Access is granted |
WRITE_DAC | Access is denied |
WRITE_OWNER | Access is denied |
Examples of Permissions Behavior for NFS RPCs in S3 Native Flavor
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 and bucket 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 or bucket 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.
Example: Uploading Objects via S3, Reading from NFS
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 no-one 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.
Example: Writing a File Under an Intermediate Directory
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.
Security Flavors Supported with Each Protocol
The security flavor options available depend on which protocols are enabled on the view:
Protocol | NFS Flavor Support | SMB Flavor Support | Mixed Last Wins Flavor Support | S3 Native Flavor Support |
|---|---|---|---|---|
NFSv3 | Yes | Yes | Yes | Yes |
NFSv4 | Yes (without NFSv4 ACLs) | No | Yes | Yes (without NFSv4 ACLs) |
SMB | Yes | Yes | Yes | Yes |
S3 | Yes | Yes | Yes | Yes |
Permissions Checking with Different Security Flavors
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 security 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 security 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 security flavor, in accordance with S3 protocol:
Access checking begins with identity and bucket policies. Policy statements that deny permission are checked first. If the requested action is denied by an identity or bucket policy, the request is denied.
If the requested action is not denied by an identity or bucket policy, and it is allowed by an identity or bucket policy, then the request is allowed.
If the requested action is neither denied nor allowed by an identity or bucket policy, then ACLs are checked. Access checking on ACLs is done in an unordered way, 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, for example, the permissions of the directory in which the file resides are ignored in permission checks.
Write permissions for NFS or SMB 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 security flavor, the algorithm used is similar to that of SMB security flavor, with variations based on the access flavor setting.
Security Flavors Summary
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 any of the protocols. | Similar to SMB. | With SMB access flavor: No With NFS access flavor: Yes |
S3 Native | No | No | Yes | No. Files and directories created by NFS and SMB 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 |