[nfsv4] Re: Interim meeting agenda topics

[Rick Macklem <[e-mail]>]

On Mon, Sep 9, 2024 at 1:14 AM Pali Rohár <[e-mail]> wrote:
>
> 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 most part, I agree with what David said.

I will admit that this sentence in RFC8881 Sec. 6.2.4 could be construed
as misleading when the server has a extended POSIX draft ACL stored
on the file object on the server.
   Bits MODE4_RGRP, MODE4_WGRP, and
   MODE4_XGRP apply to principals identified in the owner_group
   attribute but who are not identified in the owner attribute.
However, since this sentence doesn't say "only applies to principals"
and does not describe how they apply to the principals in the owner_group,
I would argue it is sufficiently vague such that it still applies to
the above case,
where there is a POSIX draft extended ACL on the file object on the server.

Further, I think it is clear that a NFSv4 client should not try and
interpret the
semantics of mode.  It should use a Access operation to determine permission.

rick

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