Articles in this section

Modifying View Policies

Sara Levy
  • Updated
Follow

Modifying View Policies via the VAST Web UI

  1. From the left navigation menu, select Element Store and then View Policies.

  2. Click ActionsButtonGUI2.png to open the Actions menu for the view you want to edit and select Edit.

  3. On the General tab, change these settings as needed:

    Name

    The name of the policy.

    Security Flavor

    The security flavor of the policy.

    The security flavor determines which protocol's access check algorithm is used and which protocol(s) is/are allowed to set permissions on files and directories. For a full description of the security flavors, see Controlling File and Directory Permissions Across Protocols. In brief, the possible values are:

    • NFS security flavor:

      • Supports NFSv3, SMB, and S3. Supports NFSv4.1 without support for NFSv4 ACLs.

      • Access checks are done according to the NFS access check algorithm.

      • NFS clients can set permission mode bits on files and directories when creating new files and directories or modifying existing files and directories.

      • Files and directories created by SMB and S3 clients receive default initial permission mode bits set in the view policy unless POSIX mode bits are set on the parent directory and enabled in the view policy, in which case they are inherited.

    • SMB security flavor:

      • Supports SMB and NFSv3. Does not support NFSv4.1 or S3.

      • Access checks are done using the SMB access check algorithm.

      • SMB clients can set permissions on files and directories.

      • Attempts by NFS clients to set permission bits are ignored.

      • Files and directories created by NFS clients inherit permissions set on the parent directory by the SMB client.

    • S3 Native security flavor:

      • Supports S3 and NFSv3. Does not support NFSv4.1 or SMB.

      • Access checks are done using the S3 access check algorithm.

      • Permissions can be changed by S3 clients using S3 ACLs.

      • 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.

    • Mixed Last Wins security flavor:

      • Supports NFSv3, NFSv4.1 and SMB. Does not support S3.

      • Access checks are done using the SMB access check algorithm.

      • Permissions can be set and modified by any client using its own protocol's permission setting system.

      • 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.

    Caution

    Switching security flavors for views that have S3 Buckets enabled is not allowed. The flavor specified in the policy when the view is created must remain.

    Vip Pools

    To limit access to specific VIP pools, select those VIP pool(s) in the VIP Pools dropdown.

    If no VIP pools are selected, all VIP pools can access all views that are attached to this view policy.

    Group Membership Source

    Determines the source to trust for users' group memberships during the permission checking process:

    Possible values:

    • Client. Groups declared in the RPC as the user's leading group and auxiliary groups are trusted and provider-sourced groups are not considered.

      This option is supported only for views that are exposed exclusively to NFSv3.

    • Providers. Group memberships retrieved from authorization providers are considered as the user's group memberships (as for SMB-only and multiprotocol views). The GIDs declared in the RPC are ignored.

      This option must be used for views that have SMB enabled.

      Similarly, where NFSv4.1 is enabled in the view, if Minimal Protection Level is set to Kerberos Auth-only, then this option must be used.

    • Client and Providers. Groups declared in the RPC and group memberships retrieved from authorization providers are considered.

      Note

      If Kerberos authentication is used by NFSv4.1 clients, the groups declared in the RPC are ignored.

    Path Length Limit

    Affects the maximum limit of file path component name length. Choose between:

    • Lowest Common Denominator (default). Imposes the lowest common denominator file length limit of all VAST Cluster-supported protocols, regardless of the specific protocol enabled on a specific view.

    • Native Protocol Limit. Imposes no limitation beyond that of the client protocol.

      Caution

      If you select this mode in a view policy and then in the future expose a view using this policy to a previously not exposed protocol, that view might contain files that won't be accessible by the newly added protocol, due to the limitations of that protocol.

    Allowed Characters

    Determines which characters are allowed in file names. Choose between:

    • Lowest Common Denominator (default). Allows only characters allowed by all VAST Cluster-supported protocols, regardless of the specific protocol enabled on a specific view. WIth this (default) option, the limitation on the length of a single component of the path is 255 characters.

    • Native Protocol Limit. Imposes no limitation beyond that of the client protocol.

      Caution

      If you select this mode in a view policy and then in the future expose a view using this policy to a previously not exposed protocol, that view might contain files that won't be accessible by the newly added protocol, due to the limitations of that protocol.

    Atime Frequency

    atime is a metadata attribute of NFS files that represents the last time the file was updated. atime is updated on read operations if the difference between the current time and the file's atime value is greater than the configured atime frequency. Consider that a very low value might have a performance impact if high numbers of files are being read.

    Specify ATIME_FREQUENCY as an integer followed by a unit of time (s = seconds, m= minutes, h=hours, d=days).

    Example: 1h

    Default: 0, which means no atime updates.

    Posix ACL

    For NFSv3 clients, this option enables full support of extended POSIX Access Control Lists (ACL). 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. To learn more about POSIX ACL, see https://linux.die.net/man/5/acl.

    If NFS security flavor is enabled, any POSIX ACLs set on directories are inherited by files created in the directory by SMB and S3 clients rather than the permission mode bits set in the view policy.

    Note

    The Posix ACL setting is supported only with the NFS security flavor.

    Note

    Thesetfacl Linux command is blocked if this option is not enabled.

    Note

    • NFSv4.1 does not support POSIX ACLs.

    • If clients have created files and directories with POSIX ACLs using NFSv3 and then they start to access those files and directories via NFSv4.1, the POSIX ACLs will have no effect.

    • If this setting is enabled, POSIX ACLs may be used via NFSv3 only. They cannot be used via NFSv4.1.

    • Support for NFSv4.1 ACLs requires Mixed Last Wins security flavor and is not supported concurrently with POSIX ACLs for NFSv3.

    Use 32-bit File IDs

    Sets the VAST Cluster's NFS server to use 32bit file IDs. This setting supports legacy 32-bit applications running over NFSv3.

    This setting is disabled by default.

    This setting is not supported for views that are enabled for NFSv4.1.

  4. Optionally, use the Host-Based Access section to restrict NFS access to the view on a host basis. You can restrict different access types.

    The access types are:

    Read Write

    The hosts that have read/write access to the view via NFS. * is a wildcard indicating all hosts.

    Read Only

    The hosts that have read only access to the view via NFS. * is a wildcard indicating all hosts.

    All Squash

    The hosts that have all squash applied to them when accessing the view via NFS. With all squash, all client users are mapped to nobody for all file and folder management operations on the export.

    No Squash

    The hosts that have no squash applied to them when accessing the view via NFS. With no squash, all operations are supported. Use this option if you trust the root user not to perform operations that will corrupt data.

    Note

    This option is not relevant for NFSv4.1 users if Kerberos is used, since AD 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 hosts that have root squash applied to them when accessing the view via NFS. With 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.

    Note

    This option is not relevant for NFSv4.1 users if Kerberos is used, since AD 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.

    Trash

    This option does not appear here by default. It appears only if Enable trash folder access is enabled on the Settings page. Granting this permission gives NFSv3 client users the ability to delete files by moving them into a trash folder, from which they are automatically deleted. Requires also No Squash. For more information, see Trash Folder (for Rapid Parallel File Deletion).

    Note

    This access type is applicable for NFSv3 clients only. The Trash folder feature is not supported for NFSv4.1 clients.

    The default configuration gives all hosts read/write access and root squashing. This is indicated by the two wildcard entries that initially appear in the Read/Write and Root Squash rows of the grid. These wildcards represent all IPs of all hosts:

    HostBasedAccess.png

    You can add hosts to any and all of the types, but within each category no more than one type will be applied to any given host. If a host is specified with multiple entries in mutually exclusive types, the conflict is resolved as follows:

    • An IP overrides a netgroup, a netgroup overrides a CIDR, and a CIDR overrides a wildcard expression.

    • If a conflict remains after the previous rule is applied, then:

      • Read Only overrides Read / Write.

      • All Squash overrides Root Squash.

      • Root Squash overrides No Squash.

    To add entries in the access type grid to allow the exact host access that you want

    1. Click the +Add new IP button for the access type you want to add hosts to.

      The IPs list for the access type becomes editable.

    2. Add hosts using any of the following expressions in a comma separated list:

      • A single IP.

      • A netgroup key, which starts with '@'. This is supported for NIS netgroups if NIS is configured. For information about how to use netgroups, see Using NIS Netgroups to Authorize Host Access to NFS Exports for more information.

      • A subnet indicated by CIDR notation. For example: 1.1.1.1/24.

      • A range of IPs indicated by an IP address with '*' as a wildcard in place of any of the 8-bit fields in the address. For example, 3.3.3.*, or 3.3.*.*.

    3. Click Add or press the ENTER key on your keyboard.

      The entries are added.

    To remove an entry, hover to the right of the entry until a removal button appears and click it:

    removeIP.png

  5. If you selected NFS as the security flavor, open the default POSIX modebits section. Here, you can change the file mode permission bits and the directory mode permission bits that are applied to files and directories when they are created by protocols other than NFS.

    To learn more about permissions and how they are transposed between the protocols, see Controlling File and Directory Permissions Across Protocols.

  6. On the NFS 4.1 tab, change the Minimal Protection Level to the minimal level of security to allow for NFSv4.1 client RPCs:

    • Kerberos Auth-only. Allows client mounts with Kerberos authentication only (using the RPCSEC_GSS authentication service).

    • System. Allows client mounts using either the AUTH_SYS RCP security flavor (the traditional default NFS authentication scheme) or with Kerberos authentication

    • None. Allows client mounts with the AUTH_NONE (anonymous access), or AUTH_SYS RCP security flavors, or with Kerberos authentication.

  7. If you intend to use this policy for S3-enabled views, select the S3 tab and set bucket listing permissions:

    • In the Bucket listing permission (users) field, enter any user names of users who should be able to list buckets that are created using this policy.

      When an S3 user sends a bucket listing request, the command returns a list of all buckets the user owns and all buckets that they have listing permission for, even if they do not have permission to access those buckets.

    • In the Bucket listing permission (groups) field, enter any group names of user groups who should be able to list buckets that are created using this policy.

  8. Click Update to save your changes.

Modifying View Policies via the VAST CLI

To modify a view via the VAST CLI, use the viewpolicy modify command.

Related articles

Comments

0 comments

Article is closed for comments.