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

[Rick Macklem <[e-mail]>]

On Mon, Jul 22, 2024 at 8:29 AM Chuck Lever III <[e-mail]>
wrote:

>
>
> > 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.
>
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.)

It appears to handle POSIX draft ACLs in a manner similar to
what new POSIX draft ACL attributes would do.  The only difference
appears to be that it provides a way for a client to query to
find out how big the ACL list is without getting the actual ACL.
(This could be done via additional new attributes, I think?)

Here's a snippet of nfs_acl.x that I found interesting...
/*
 * XXX {
 * This is a transitional interface to enable Solaris NFSv4
 * clients to manipulate ACLs on Solaris servers until the
 * spec is complete enough to implement this inside the
 * NFSv4 protocol itself.  NFSv4 does handle extended
 * attributes in-band.
 */

/*
 * This is the definition for the GETACL procedure which applies
 * to NFS Version 4 files.
 */
struct GETACL4args {
nfs_fh4 fh;
u_int mask;
};

struct GETACL4resok {
post_op_attr attr;
secattr acl;
};

struct GETACL4resfail {
post_op_attr attr;
};

union GETACL4res switch (nfsstat3 status) {
case ACL4_OK:
GETACL4resok resok;
default:
GETACL4resfail resfail;
};

/*
 * This is the definition for the SETACL procedure which applies
 * to NFS Version 4 files.
 */
struct SETACL4args {
nfs_fh4 fh;
secattr acl;
};

struct SETACL4resok {
post_op_attr attr;
};

struct SETACL4resfail {
post_op_attr attr;
};

I found the comment amusing.
Note that "secattr" is the POSIX draft ACLs similar to what I
proposed as new attributes for NFSv4.2.
(The "mask" in the argument seems to indicate whether the client
wants the count of entries in the ACL or the actual ACL.)

Note that there are basically identical definitions for NFSv2 and
NFSv3, except for the nfs_fh version.

rick


>
> --
> Chuck Lever
>
>
>