Background
A common configuration for VAST customers is to expose the root of the Elementstore (i.e., “/”) to certain client systems for administrative purposes while limiting or outright denying mounting and browsing for all others. This is easily accomplished for NFSv3 by using Host-Based options in the View Policy, specifically setting and limiting NFS Read-Write and NFS No Squash to only include those administrative clients. However, NFSv4 is more complex because of how it works.
Unlike NFSv3, NFSv4 shares are exposed as part of a virtual filesystem with a filesystem tree starting at “/” (root), with each export as a subdirectory. While administrators can mount the desired path directly, as with NFSv3, they can also mount the NFSv4 share at “/” and traverse down. Indeed, even when issuing an NFSv4 mount command to a specific share in the tree, the system traverses this virtual filesystem and applies traditional traversal rules.
Unlike traditional NFS servers, whose NFS exports cover both NFSv4.1 and NFSv3 unless the system is limited to one or the other, VAST clusters allow shares (Views) to be exposed via NFSv3 and/or NFSv4.1 individually. With nested Views, for example, /parent and /parent/child, this can create issues with client protocol negotiation if the /parent and /parent/child views are exposed with different combinations of NFSv3 and NFSv4.1. As such, NFSv4 has two requirements. Either:
No NFS-enabled Views are defined higher in the directory tree
If a View that is higher in the directory tree is exposed via NFS, it must be exposed with NFSv4.1.
As such, any administrative View that exposes “/” via NFSv3 must also expose it via NFSv4.1.
This also introduces a new issue due to how NFSv4.1 functions in that “/” and all directories in the tree must be traversable by clients. This also means that a client must have read-only access to “/”. The directories don’t necessarily require the ability to do directory listings, but they must be traversable. Traditionally, traversing directories is controlled by the “x” bit.
[vastdata@pwags-se-lin1 ~]$ sudo mkdir /mnt/nfsv4-view
[vastdata@pwags-se-lin1 ~]$ sudo mount -vv -o vers=4,sec=sys nfs.selab-var202.selab.vastdata.com:/nfsv4-view /mnt/nfsv4-view/
mount.nfs: timeout set for Fri Aug 30 10:56:53 2024
mount.nfs: trying text-based options 'vers=4.1,sec=sys,addr=172.200.202.96,clientaddr=172.200.13.155'
mount.nfs: mount(2): Operation not permitted
mount.nfs: Operation not permitted
[vastdata@pwags-se-lin1 ~]$Implementation
The question then is: how do we maintain administrative capabilities, including root access, while also preventing clients from mounting “/” via NFSv4.1 and potentially viewing sensitive Views/Directory names?
Let’s start with the View Policy. The “default” View Policy is created upon install by, well, default. The default View Policy is of the NFS Security Flavor and is automatically applied to a View for “/”, which has NFS (NFSv3) enabled as a protocol. If you don’t wish to have “/” exposed at all for anything, just remove the view on “/” and create your Views, including NFSv4.1 views as desired. Problem solved.
However, if you wish to maintain administrative access and limit it to certain clients, we’ll need to make some changes. Either edit the existing default View Policy or create a new View Policy with the following settings:
Security Flavor: NFS
VIP Pools: Leave This Blank so it covers exposure on all VIP pools
No Squash: List of the IP addresses of the Clients that you want to allow administrative access to.
Root Squash: Either leave blank or “*” (Everyone)
Read-Write: List of the IP addresses of the Clients that you want to allow administrative access to.
Read Only: “*” (Everyone) <---- Must be populated. Leaving this blank will deny access.
Then, expose “/” using either the modified default policy or change it to use this new policy. For protocols, expose via NFSv3 and NFSv4.1 or only via NFSv4.1.
At this point, any client will be able to mount “/”. Except for the clients listed in Read-Write in the View Policy, Clients will be read-only and can perform a directory listing, showing all directory and View names.
To restrict directory listings, we must change the permissions at “/”.
From an administrative client whose IP address is in Read-Write and No Squash, mount the “/” View, either via NFSv3 or NFSv4.
Become root (uid 0) or use sudo to chmod the permissions on “/” to 771.
ie.
# sudo mount -o vers=4, sec=sys main.selab-var204.selab.vastdata.com:/ /mnt/var204
# cd /mnt/var204
# ls -ld .
drwxrwxrwx. 2 root root 4096 Jan 2 13:28 .
# sudo chmod 771 .
# ls -ld .
drwxrwx--x. 2 root root 4096 Jan 2 13:28 .From any other client, while the client can mount “/” via NFSv4, they will not see any directories or files. They can navigate to and mount other Views down the tree, and the View Policies of that View apply.