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

[Chuck Lever III <[e-mail]>]

> On Jul 5, 2024, at 4:09 PM, Rick Macklem <[e-mail]> wrote:
> 
> On Thu, Jul 4, 2024 at 5:22 AM David Noveck <[e-mail]> wrote:
>> 
>> I'd appreciate it if you took a look at what I've done to better support draft POSIX ACLs in NFSv4.1 and let me know your thoughts.
> I have glanced at it. I think my opinion is already well known,
> however it does not matter..
> Why?
> Because Trond will decide what goes in the Linux NFSv4 client and
> NFSv4 server implementors will do
> whatever the Linux NFSv4 client wants/needs.
> I have encouraged Trond to comment. Until he does, I do not see any
> reason to proceed further w.r.t. POSIX draft ACLs vs NFSv4 ACLs.
> 
> W.r.t. servers that implement a subset of NFSv4 ACLs natively, I will
> comment on [e-mail] if/when I have a
> chance to look at what your draft proposes and compare that with what
> OpenZFS currently does.
> (I doubt the OpenZFS ACL semantics can change, but ??)
> 
> rick
> 
>> 
>> There is a lot of work directed toward such support in acls-04.   It takes a different approach than your earlier proposal to create two new acl attributes in that it treats the issues within the framework of the existing ACL model, albeit with some major conceptual restructuring (but leaving the existing XDR pretty much intact.).
>> 
>> I am still open to approaches that strive to be more draft-POSIX-ACL-oriented as discussed in my Appendix C.1 but feel those will have to wait until NFSv4.2.   It would be good if we can discuss those and  get enough agrrement to start implementation work on a common approach to these issues.
>> 
>> Right now, I'm prototyping the draft-POSIX-ACL support described within acls-04 and I have no immediate plans to try anything in Appendix C. However, if you have plans for client implementation work for draft-POSIX-ACL-related implementation work, I could look at doing some v4.2 prototype to match.   I think we could do this before drafting a proposed v4.2 extension.

For unrelated reasons I'm currently looking at the Linux NFSACL
implementation, and questions about how that will relate to any
future NFSv4 POSIX ACL implementation started to bubble up in my
mind.

Reading acl04, I find few if any references to preceding efforts
to handle POSIX ACLs within the framework of NFS.

One place to start addressing that omission is to understand how
POSIX ACLs are handled by the pre-existing NFSACL protocol, and to
consider making any NFSv4 POSIX ACL extension compatible with that
work. That will help make existing implementations of POSIX ACLs
on NFSv3 more straightforward... not to mention preventing semantic
changes between NFSv3 and NFSv4 mount points that would make
deploying NFSv4 POSIX ACL support needlessly fraught.

However, that would require surfacing a specification for the
NFSACL protocol. If one exists, it no doubt will have similar gaps
in its discussion of ACL and authorization semantics as the ones
Dave attempts to address here. (ie, it is indeed a challenging
subject to write about).

Btw, I'm not suggesting that I currently know that such a
specification is available. To my knowledge, independent
implementations of NFSACL were reverse-engineered from the
Solaris on-the-wire behavior.


--
Chuck Lever