[nfsv4] Re: Interim meeting agenda topics

[Pali Rohár <[e-mail]>]

On Sunday 08 September 2024 19:24:27 David Noveck wrote:
> 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.

Sorry for that, I was not clear enough. Model is fine, POSIX ACL
extension and POSIX ACL attributes are fine too.

My point was about existing NFS4 attributes 33 (mode) and 74 (mode_set_masked).
Meaning of these NFS4 mode attributes (in both NFS4.0 and NFS4.1/NFS4.2) is
slightly different than what IEEE POSIX ACL draft requires.

It is similar to the issue that NFS4 ACL attributes 12, 58 and 59 are
different than IEEE POSIX ACL. And this was solved in extension document
by allocating a new attributes which would serve POSIX ACL structures.

In my personal opinion, the best would be if also for POSIX ACL mode
would be allocated new attribute, in exactly same way as was added POSIX
ACL attributes. So it would be present only if file has POSIX true ACL
form. And let existing attribute 33 for its original meaning (from
RFC8881) independently of what is the true form.

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

The problem is with existing server which via MODE4_RGRP, MODE4_WGRP and
MODE4_XGRP controls permissions of the OWNER_GROUP-only (per RFC8881).
So changing these bits never affects principals with kerberos ticket
which does not contain OWNER_GROUP in it. Clients using this NFS4 server
can have a contract that this would always apply as a security thing.

Now, if the existing server implements POSIX ACL extension then for
files which are in POSIX ACL true form would have to change meaning of
MODE4_RGRP, MODE4_WGRP and MODE4_XGRP bits. This server can serve data
to both new POSIX clients (which will implement this extension) and also
to clients from previous paragraph (without POSIX extension). So the
NFS4 POSIX client with the POSIX extension (e.g. Linux or FreeBSD) can
set ACL on new (or existing) file (ACL for more ACL_USER and ACL_GROUP),
and server will automatically change true acl from from NFS4 to POSIX.
All this is fine. The problem happens now when the non-POSIX NFS4 client
from previous paragraph wants to just change permissions for users
affected by primary group. So this client from previous paragraph per
contract arguments will just change MODE4_*GRP bits and it will expect
that this change does not affect permissions of other users. But in
reality it will change access to everybody except ACL_USER_OBJ and
ACL_OTHER, per IEEE ACL draft (as MODE4_*GRP controls MASK). And this
will break the contract for existing clients from previous paragraph.

So if these existing servers do not want to break contract with existing
non-POSIX NFS4 clients then they either are disallowed to implement
POSIX ACL extension. Or they would have to somehow figure out if the
connected client is POSIX-compatible or is not with this POSIX
extension. For server one option could be to inspect OP_EXCHANGE_ID
request (client put there its identification) and based on this the
server can "detect" if the client is POSIX or not, and "process"
attribute 33 in different way for POSIX and non-POSIX clients.

Now if I'm looking at this, the best for these scenarios can be to
separate POSIX ACL mode bits into new NFS4 attribute. So existing NFS4
clients can use attribute 33 as before, server would process attribute
33 always as before (so server can MODE4_*GRP map just to group owner,
not to mask). And for files in ACL true form there would be new
attribute and POSIX client with this extension would know that the
MODE4_*GRP of this new attribute would be MASK (if the POSIX ACL has
MASK entry). This would allow for existing servers to have coexistence
with existing non-POSIX NFS4 clients, new POSIX NFS4 clients with
extension. And also would allow servers to continue serving in attribute
33 what was there before, independently of the true ACL form. Like for
attribute 12, where server can provide POSIX-MAPPED-to-NFS4 form.

Hopefully, this is more clear what I mean about forward and backward
compatibility.

Anyway, it is up to you. I'm just trying to show some examples of the
real issues and solution for it, to prevent future problems.