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

[Rick Macklem <[e-mail]>]

On Wed, Jul 24, 2024 at 7:59 AM Chuck Lever III <[e-mail]>
wrote:

> Hi -
>
> > On Jul 24, 2024, at 8:43 AM, David Noveck <[e-mail]> wrote:
> >
> > Rick has discussed the possibility of a v4.2 extension but using new
> attributes has not committed to writing it up.   I'm worried that he might
> lose interest given the possibility of IP horrors, but I really don't know.
> From my point of view, the weakness in Rick's approach is that it does not
> address migration and coexistence issues.  I think that is essential given
> the history here but many files with ACLs exist on file systems and I think
> it's important to address the issues of how the existing model and a new
> one will interact.
>
> Hence my concern about how POSIX ACLs might appear to clients
> that access them via NFSv3's NFSACL versus how they might
> appear to clients that access them via a putative NFSv4 POSIX
> ACL facility. NFSv3 remains a widely-deployed protocol and I
> believe users would be surprised if there were compatibility
> issues.
>
> If there are no issues here, great! If there are, IMO new
> documents should help implementers and users understand and
> cope with any differences.
>
The only difference I can think of would be uid/gid vs
owner@domain/owner_group@domain.
(This imcompatibility is no different than what will already
happen for NFSv3 vs NFSv4.2.)

Other than that, both would simply set/get the POSIX draft
ACLs and the server's file system would implement the semantics.
(Disclaimer: I do not know the NFSACL protocol beyond what the
nfs_acl.x file shows.)

rick


> Given that you believe "it's important to address the issues
> of how the existing model and the new one interact" I hope
> you will provide some guidance in this area in acls-0? or
> follow-on documents. :-)


>
> --
> Chuck Lever
>
>
>