[nfsv4] Re: Interim meeting agenda topics

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

On Monday 09 September 2024 13:57:57 David Noveck wrote:
> On Mon, Sep 9, 2024, 4: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.
> >
> 
> I don't understand how the "meaning" is different.  As I understand it,
> neither Rick's document nor the definition  changes the meaning of the
> mode.  These documents do change the value of the mode attribute so that it
> reflects the ACL set.  However, the two documents agree on this setting, as
> they should.

Different is meaning of MODE4_*GRP as I described below. IEEE ACL
requires that MODE4_*GRP controls ACL_MASK ACE which applies to
everybody except ACL_USER_OBJ and ACL_OTHER entries. But in RFC8881 in
part 6.3.2.1. discouraged from doing this is. So meaning is quite
different for servers which fully follows RFC8881 advices.

> 
> > It is similar to the issue that NFS4 ACL attributes 12, 58 and 59 are
> > different than IEEE POSIX ACL.
> 
> 
> It is quite dissimilar.  The NFSv4 attributes you mentioned were intended
> to be different than draft POSIX ACLs.  That was probably a mistake, but we
> can't undo that mistake now, decades later.

Ok.

> And this was solved in extension document
> > by allocating a new attributes which would serve POSIX ACL structures.
> >
> 
> It will be solved once we publish that as an RFC.
> 
> >
> > 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.
> 
> 
> I understand thatis your personal opinion.  We need to here  a reason to
> add a new attribute.
> 
> > So it would be present only if file has
> > POSIX true ACL
> 
> > form.
> 
> 
> But why?

I thought that this is how to follow new POSIX acl attributes (default
and access) which are present only for POSIX true ACL form. (Ok, my word
"present" is misleading in this context, attributes are always present,
but value is not provided for non-POSIX-true-acl-form, as Rick wrote in
POSIX extension document).

> And let existing attribute 33 for its original meaning (from
> > RFC8881) independently of what is the true form.
> >
> 
> The meaning has been the same fron rfc3010 onwards.
> 
> >
> > > 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.
> >
> 
> There is no such contract although people might have such an expectation.

Sorry, I wrote it improperly. I mean that in industry world, (server)
behavior is written into stone and client lot of times depends on it.
And because server lot of times guarantee stable behavior to customer
(and SW clients), it is de-facto contract which cannot be changed,
specially in industry where is backward compatibility the must.

So yes, there is no real "contract" but people and software, specially
in industry has this expectations on existing software.

> 
> > 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.
> 
> 
> The meaning is not changed.
> 
> 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.
> 
> 
> If he has this expectation with regard to a local file, what happens?  My
> understanding is that the effect would be the same as that provided for by
> Rick's document.  If it isn't,  we have a problem and we can discuss how to
> fix it.

It is not same. And that is why I bring it here.

NFS4 server per RFC8881 does not have to control ACEs for named users
and named groups via MODE4_*GRP bits. But IEEE ACL draft requires it.

So behavior would be same only and only for NFS4 servers which already
controls/maps MODE4_*GRP to POSIX ACL MASK.

For other NFS4 servers which are not doing it, the behavior would not be
same.

> It is possible that the decision to define the mode interaction in
> this way was a mistake but our chances of fixing something like that now
> are just about non-existent.

I have same feeling. That is why I proposed an idea how to fix it by
defining a new true-POSIX-mode attribute, which would guarantee the
correct behavior between MODE4_*GRP and ACL MASK.

> > 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.
> >
> 
> You are very unclear when you refer to "POSIX"  and "NON-POSIX" clients and
> when you confuse user expectations with contracts.

By POSIX client I mean the client implementing new NFS4 POSIX ACL
extension. And non-POSIX client the one which does not implement it and
is not aware about existence of it and has different expectations what
MODE4_*GRP controls (different from IEEE POSIX ACL).

> 
> > 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.
> >
> 
> Fair enough.  It is up to Rick whether he wants to mention issues regarding
> the unexpected results of changes in group bits.  If he does, we can
> summarize the issues.  As far as fixing these issues, we cannot go past
> matching the behavior of unmediated local access.

Ok.