[nfsv4] Re: Our different approaches to draft POSIX ACL support in NFSv4

[Trond Myklebust <[e-mail]>]

On Wed, 2024-07-24 at 18:02 -0700, Rick Macklem wrote:


On Tue, Jul 23, 2024 at 11:09 AM Trond Myklebust <[e-mail]<mailto:[e-mail]>> wrote:
On Tue, 2024-07-23 at 15:27 +0000, Chuck Lever III wrote:
>
>
> > On Jul 23, 2024, at 10:27 AM, Trond Myklebust <[e-mail]<mailto:[e-mail]>>
> > wrote:
> >
> > On Tue, 2024-07-23 at 13:54 +0000, Chuck Lever III wrote:
> > >
> > > > On Jul 22, 2024, at 7:13 PM, Rick Macklem
> > > > <[e-mail]<mailto:[e-mail]>>
> > > > wrote:
> > > >
> > > > I just looked at opensolaris/usr/src/head/rpcsvc/nfs_acl.x
> > > > which I think is the closest thing there is to a spec. for
> > > > NFSACL.
> > > > (FreeBSD does not implement this protocol and all I know about
> > > > it
> > > > is what this little .x file indicates.)
> > >
> > > That's excellent, thanks for finding it.
> > >
> > > My concern about this is that the cited .x file falls under
> > > CDDL, and thus cannot be used directly by a GPL-encumbered
> > > OS like Linux, nor can it be contributed to the IETF in its
> > > current form.
> > >
> > > This is clearly prior art.
> > >
> > > My question then is whether we should endeavor to produce
> > > an Informational document that describes NFSACL without
> > > encumbrance -- ie, get Sun-Oracle to contribute that work
> > > so that it might be used openly.
> > >
> >
> > Why do we care?
>
> As I explained, we do want to have a protocol specification
> for NFSv4 that will not be disruptive to folks who were using
> NFSv3 and are now accessing the same ACLs via NFSv4.2+

No we don't.

We need a new protocol specification that works correctly with the
draft POSIX acls in use with existing Linux and other filesystem, and
that supports all the features of the IEEE 1003.1e draft 17 document
that were implemented within Linux and the *BSD.
Once we have that, I will happily plug that implementation into the
inode 'get_acl()' and 'set_acl()' callbacks, and people will be able to
use the bog standard getfacl and setfacl utilities to control the POSIX
ACLs as if they were running on a native filesystem.

Ok. It sounds like you support the concept of extending NFSv4.2
to support POSIX draft ACLs.  If this is not the case, please
clarify this?

I agree that we should treat POSIX draft acls as being something very different than NFSv4 acls, and that it makes sense to extend the NFSv4.2 protocol to support them. We've tried to create mappings between the two for over 2 decades now, and the conclusion has always been that such mappings lead to security compromises that are not always acceptable to end users, particularly when trying to map arbitrary NFSv4 acls into POSIX draft acls.

Given the above, I will get back to writing a IETF draft describing
POSIX draft ACL attributes as I prototyped them, as a starting point
w.r.t. this.

rick

I think that would be a very useful effort if we want to fully integrate all the filesystems that use them into the NFS ecosystem.

I also think that if someone does still want to build a mapping between NFSv4 acls and POSIX draft acls, then this effort does not preclude them from doing so. Instead, it would allow them to do so in userspace, where the security nuances are perhaps easier to resolve with active help from the users.


--

Trond Myklebust
CTO, Hammerspace Inc
1900 S Norfolk St, Suite 350 - #45
San Mateo, CA 94403
​
www.hammerspace.com