[nfsv4] Re: Interim meeting agenda topics

[David Noveck <[e-mail]>]

On Sun, Sep 8, 2024, 6:12 PM Rick Macklem <[e-mail]> wrote:

> On Sun, Sep 8, 2024 at 9:34 AM Pali Rohár <[e-mail]>
> wrote:
> >
> > On Sunday 08 September 2024 12:05:54 David Noveck wrote:
> > > On Fri, Sep 6, 2024, 4:35 PM Rick Macklem <[e-mail]>
> wrote:
> > > > What is left to be resolved / is controversial on the POSIX_ACL
> draft?
> > >
> > > Nothing from my point of view.  I don't know of any issues Rick has.
>  It
> > > is reasonable to expect that anyone who does have issues to raise them
> on
> > > the list.   We may need to confirm the non-existence of such issues at
> the
> > > forthcoming interim meeting.  I think we should allocate five minutes
> for
> > > this.
> >
> > Hello, I have already pointed one issue on the list - problem with mode
> > attribute (two meaning modes: NFS4 and POSIX) and its backward/forward
> > compatibility on existing NFS4 servers for clients without POSIX ACL
> > extension.
> I'll admit I just do not understand what you are thinking.
>

My response is the same.  I guess we need to discuss this at the next
interim meeting.

For the proposal, at any one moment in time, a file object on the server
> will have, at most, one "true form" ACL. (Where "true form" is the ACL
> that is stored for the file object and used to determine access to the
> file.)
>

The treatment in the latest acl draft is consistent with that model.  It
provides for extensions such as yours, which define additional ACL models
with the assumption being that there will be at most one ACL model in
effect for any fike system object at any time.  The job of defining new ACL
models is left to extensions as such as yours.

>
> As such, I cannot understand why you would think there are two modes?
> (Where "mode" refers to the low order 9 bits of the mode attribute.)
>
> The interaction between setting of the low order 9 bits of mode and the
> setting of an ACL is determined by which "true form" the ACL has.
>

Yes.  According to the latest ACL draft, the job of defininin those
interactions in job of the acl document only when the ACL model in effect
for that object I'd the NFSv4 ACL model.  When it is any other ACL model,
it is the job of the standards-track extension defining that new ACL
model.

>
> For the weird case where a SETATTR is allowed to set an ACL of the
> other "true form" for a file object, the mode bits will be updated the
> same way as they would be if that ACL was set for the file object at
> any other time (ie. no previous ACL or a previous ACL of the same "true
> form"
>

Agree. Although you describe this case as wierd, I cannot disagree but have
to point out that this is much less weird than a number of presidential
candidates :-)

>
> W.r.t. clients that do not support the extension...
> These clients might set the mode bits and the effect would be no
> different than what occurs now.
> --> For a server that uses a "true form" of POSIX draft ACL, that
>      ACL might change, just as would happen now. It's just that the client
>      cannot actually "see" the ACL.
>
> W.r.t. servers that do not support the extension...
> The attributes will not be in the supported_attrs list and any
> attempt to GET/SET them should fail.
>
> rick
>