Background
A common configuration for VAST customers is have the root of the Elementstore (ie, “/”) exposed to certain client systems for administrative purposes while limiting or outright denying mounting and browsing ability 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, for NFSv4, it becomes a bit more complex due to how NFSv4 functions.
Unlike NFSv3, NFSv4 shares are exposed as part of a virtual filesystem with a filesystem tree starting at “/” (root) and having each export as a subdirectory. While in most cases administrators would simply mount the desired path directly as they would with NFSv3, it is possible to mount the NFSv4 share at “/” and traverse down. Indeed, even when issuing an NFSv4 mount command to a specific share in the tree, a traversal of this virtual filesystem occurs and is subject to traditional traversal rules.
Unlike traditional NFS servers, whose NFS exports cover both NFSv4.1 and NFSv3 unless the system as a whole 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, when using NFSv4, there are 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.1,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 will be able to 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.1, 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 .When looking from any other client, while the client can mount “/” via NFSv4, they will not see any directories or files. They will be able to navigate to and mount other Views down the tree and have the View Policies of that View apply.