Views are entities that expose directories over file sharing protocols. Views can be configured to expose a directory over the following file sharing protocols:
NFS. Multiple NFSv3 views can be created. One can be enabled for NFSv4.1 also, subject to several limitations.
SMB
NFSv3 and SMB simultaneously (referred to here as multiprotocol)
S3, also a supported protocol, is exposed using a different mechanism. For information about working with S3, see Using S3 Storage.
The ability of a client host to mount a view is controlled differently depending on the client's file sharing protocol:
On SMB clients, access is controlled by user account. SMB shares are supported with the requirement that the cluster is joined to an Active Directory service. SMB users are, by default, authenticated via Kerberos according to their user entries on the Active Directory server. NTLM authentication is also supported as a fallback authentication method.
On NFS, host access is controlled through host IPs. 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.
Each of the file sharing protocols supported by views has its own system for managing permissions on files and directories. NFS uses permission mode bits with the option of POSIX ACL extensions. SMB uses NTFS Access Control Lists (ACLs). Internally, VAST saves a proprietary protocol-independent type of file permissions on each file and maps the VAST permissions to each protocol's permissions.
There are three different models that you can choose between which determine exactly how permissions are managed in a multiprotocol view. They are called security flavors. Security flavor is set in the view policy. Different views can use different view policies and therefore the security flavor can be set differently per view.
The security flavors are:
NFS security flavor treats NFS as a native protocol and SMB as a non-native protocol.
NFS clients may set and modify file and directory permissions. Attempts by SMB clients to set or modify file and directory permissions fail. Since SMB cannot set permissions, default permission mode bits are defined in the view policy. The default permission mode bits are applied as initial permissions to any files and directories that are created by SMB clients.
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 security flavor treats SMB as a native protocol and NFS as a non-native protocol.
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.
Mixed Last Wins flavor allows file and directory permissions to be set and modified by both NFS and SMB clients. The implications of this are not straightforward in some scenarios. 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.
For specific scenario handling with Mixed Last Wins see Scenario Handling with Mixed Last Wins.
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 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? |
Requires administrator to define initial object permissions for a non favored protocol? |
Permission Checking Algorithm |
|---|---|---|---|---|
NFS |
Yes |
No |
Yes. In the view policy, the administrator defines permission bits to be applied to new files and directories created via SMB. |
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. |
SMB |
No |
Yes |
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. |
Mixed Last Wins |
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. |
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 |
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 bitsIn 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.
File CreationWhen 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 permissionsIf 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 permissionsA 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.
Accessing Sub-Directories via SMB Requires Traverse PermissionsIn 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.
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.
Comments
0 comments
Article is closed for comments.