More flexible NFSv4 viewpolicies

Product Feedback
1

To preface this, I don’t know if this is strictly speaking possible with the NFSv4.1 protocol.

TL;DR:
NFSv4.1 enabled Views with different Security requirements should function independently of one another if the networks in those Views don’t overlap.

Explanation:
We run an unusual environment, with the same storage serving Macs (SMB), Windows (SMB), and Linux desktop and laptop clients (NFSv4.1), Linux servers (NFSv3), and our Linux based HPC/HTC cluster (NFSv3). We do not have HPC specific storage.

In order for all of this to work and permissions to remain sane, we force everything to the POSIX mode bits/permission model. We do not currently use ACLs at all. SMB clients are not permitted to change permissions, so we set Default POSIX Modebits in the View Policies.

A vocal contingent of my users would like two things that we can’t currently provide:

  • Inheritable permissions. For example, the ability to have group write permissions inherit from the parent directory over NFS on Linux, without having to globally change or set their umask.

  • The ability to have more flexible permissions than the POSIX model allows. For example, they would like to be able to set read/write permissions for a single user outside of their group on a particular file or directory without having to have that account added to their group.

The obvious answer of this is to start using ACLs, as painful as that might end up being for me as an admin and for the folks who don’t need the functionality above. However, we cannot do this currently because of the NFSv3 clients. NFSv4 and SMB ACLs don’t map cleanly to POSIX mode bits, and NFSv3 ACLs are completely incompatible with them. This would lead to highly inconsistent behavior between platforms, which is something my users are very, very much not accustomed to.

The other obvious avenue would be to switch the servers and HPC cluster over to using NFSv4.1 with ACLs. While on the surface this seems doable, all of our NFSv4.1 exports/views require KRB5. Becaus KRB5 has inherent ticket expiration dates, past which the tickets cannot be renewed, this is a very poor fit for servers and HPC jobs that may run longer than the 7 day expiration policy.

OK, then I could just create parallel exports with NFSv4.1 and System level security on the same paths as the NFSv4.1/KRB5 security exports. NOPE. This is not allowed by Vast (and/or NFSv4.1); even if I mount the system level security export at a higher level than the krb5 export, as soon as you traverse to a directory that would fall under the krb5 export, krb5 requirements apply.

If at all possible, I would like to be able to have this scenario work, where if a client mounts at the System security views from a network that is configured in that export/view, that should be the only security required for that client.

1 Like
2

Pinging @eyal.traitel and @tomer.hagay for this!

3

Hey @carlilek ! definitely challenging use case. If we’ll support inheritable permissions as you mentioned, would that provide a better setup for you? It’s hard to see us implementing the flexible permissions you mentioned since there are ACLs indeed…

4

Hi Eyal,

My ask is more around NFSv4 security requirements–going to NFSv4 and SMB (removing NFSv3 from the equation) would give me the flexibility my users are looking for as well as the inheritance.

We need to mantain KRB5 security for several subnets within the building, which have desktops and laptops connected to them.

For networks in our datacenter (and in particular our HPC cluster), we cannot use KRB5 security because of the ticket renewal timeouts involved.

However, both sets of networks need to have access to the same data. Currently this is achieved by not exporting NFSv4 to the datacenter networks, only NFSv3, and not exporting NFSv3 to the building subnets, only NFSv4.1.

We cannot currently export NFSv4.1 to the datacenter networks with SYSTEM level security, because as soon as a client traverses into a directory that falls under the building NFSv4.1/KRB5 exports, the KRB5 requirement applies.

As I write this, I wonder if this is only because the NFSv4 exports are set to read/write for * as opposed to specific networks. I will need to experiment!

EDIT:
I have experimented, and it doesn’t work this way, either.

This is incredibly complex to document, so I will move over to my Slack channel with the details.

1 Like
5

This is a great discussion, thank you @carlilek. I’ll put a note to make sure that we share the end result of the Slack conversation as well.

1 Like