[nfsv4] Re: Interim meeting agenda topics

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

On Monday 09 September 2024 18:33:20 David Noveck wrote:
> On Monday, September 9, 2024, Rick Macklem <[e-mail]> wrote:
> 
> > 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.

I agree that it is misleading. But it cannot be easily changed because
this is something which NFS4 servers can follow and already follow. So
it is required to deal with it.

> It is the same sort of issue when there is an NFSv4 ACL in place.   It dies
> not make clear that the mode is only used to control access when there is
> no ACL.

It is not clear, but the reality is that _changing_ mode (meaning to set
or clear some bits) to affects permissions of existing ACL is commonly
used by admins (over NFS4 clients) and also is implemented on existing
NFS4 server to modify NFS4 ACL in some sane manner. This is AFAIK also
NetApp's behavior.

> I believe this is clarified in the new treatment of authorization in the
> new security document.
> 
> 
> >    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.
> 
> 
> I don't  think of that vagueness as a good thing.  To me, it is something
> to be eliminated.

It is vague, I agree with you. And it allows new NFS4 server
implementations to choose from more options. But changing behavior on
existing NFS4 server, specially in industry where everything must be
backward compatible, is hard and sometimes impossible.

So changing something which is already released in the real word would
be really hard.

> 
> >
> > Further, I think it is clear that a NFSv4 client should not try and
> > interpret the
> > semantics of mode.

Interpreting - by reading current value is one thing. But changing mode
to new value is something different. Client has to know what is the
meaning of each bit in mode. Otherwise client would not be able to
figure out what is happing. This is crucial for any security mechanism.
It is required to know what each bit controls from security point of
view. This is something which is documented and in security environment
tested that works correctly - according to documentation.

> 
> Perhaps not but POSIX defines the semantics of mode and we should not
> change that.

Yes, IEEE POSIX ACL draft exactly defines mapping, and of course POSIX
defines semantics.

And this can be even more vague and misleading. If NFS4 client should
not try to interpret semantics of mode and IEEE POSIX ACL draft defines
semantics for POSIX applications, what does it mean for NFS4 POSIX ACL
extension which refers to IEEE POSIX ACL draft? One interpretation can
be that NFS4 client should interpret mode (because of IEEE POSIX ACL
draft).

> >
> >   It should use a Access operation to determine permission.
> 
> 
> True but we have to get away from the previous practice in rfcs 3530, 7530.
> 5661, and 5882 in which thus recommendation was rearing as giving license
> to server to implement authorization however it chooses to do so.  That is
> unacceptable.

I agree with you. But get rid of it in NFS4.1/4.2 means either breaking
compatibility which is basically no-go for industry world. Or defining
new e.g. NFS4.3 version (which is incompatible for existing NFS4
clients) or defining new attributes and operations with new "fixed"
meaning into NFS4.1/4.2 versions.

Anyway about Access operation, I agree that it should be used instead of
reading mode (or ACL) and interpreting it. But there is still an problem
with setting new mode (or new ACL) for particular to achieve some
permissions. Access operation here does not help, it is needed to know
exact meaning of all mode bits (or ACL bits, depending what is being
set).

And definition of Access operation in RFC8881 is also vague or at least
it was not clear for me (I already wrote about it in email sent before).

So I think this is really hard to do changes without affecting existing
NFS4 software which was already released and would be there for a longer
time.

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