[nfsv4] Fwd: Re: New Version Notification for draft-dnoveck-nfsv4-acls-01.txt

[David Noveck <[e-mail]>]

---------- Forwarded message ---------
From: David Noveck <[e-mail]>
Date: Thu, Jun 13, 2024 at 10:13 AM
Subject: Re: [nfsv4] Re: New Version Notification for
draft-dnoveck-nfsv4-acls-01.txt
To: Rick Macklem <[e-mail]>


> >  >        POSIXACE4_TAG_MASK         = 5,
> >
> > I have no idea what this does.

>Sec. 3 of the Eriksen, Fields draft gives you a very nice description of
them.

True.

(Better than I could write.)

I'm not convinced of that, although it seems that it is better than you are
willing to write.  I think that's a problem. YMMV.

It's still in the datatracker and I think
you could crib it?

 https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-acl-mapping-05

Unfortunately it is isn't in the nfsv4 documents page even though other
expired working group drafts are.  Not sure why.

>Btw, Sec. 5 of this draft shows you the case where a POSIX draft ACL
>cannot be expressed as a NFSv4 ACL. The existence of this case is one
>reason why I think separate attributes for POSIX draft ACLs is appropriate.

I don't think this an important issue since section 5 describes it as a
"minor eccentricity" and section 6.1 calls it a "minor exception".
You may disagree but I would suggest you consider the negative effects of
creating a new acl attribute cut off from extensions provided in v4.0, even
though a poor job was done there.  What should have been done then and what
I think should be done now is to make the  unix acls the base, in an
extensible form, and alow extensions to be suported as people indicate a
need for them.   To me, that means working toward semantic harmonization,
rather that seizing on any difference in semantic dtail as a reason to hoot
nfsv4 acls in the head and move on.


> (The other is the default ACL. See the end of Sec. 3 of the draft and
below.)

Will address that later.

>
>  >        POSIXACE4_TAG_OTHER        = 6
>
> Currently, NFSv4 has EVERYONE@.   OTHERS@ would be a help and could be
added in v4.2.   I don't think it could be added in v4.1, but perhaps a
case or it could be made.
Without the rest of the POSIX draft ACL stuff, I do know if this would
be useful?

I don't know either but it still worth thinking about.

>
> > };
>
> > typedef uint32_t        aceperm4;
>
> /* Bit definitions for aceperm4. */
> > const POSIXACL4_PERM_EXECUTE    = 0x00000001;
> > const POSIXACL4_PERM_WRITE      = 0x00000002;
> > const POSIXACL4_PERM_READ       = 0x00000004;
>
> >struct posixace4 {
> >        acetag4         tag;
> >        aceperm4        perm;
> >        utf8str_mixed   who;
> > };
>
> > And I defined two new attributes:
>
> > posix_access_acl      posixace4<>;
> > posix_default_acl     posixace4<>;
>
> > Is there a reference that explains default_acl.?
>The end of Sec. 3 of the Eriksen, Fields draft.
>Basically, directories can have both an access and default ACL.
>The default ACL is only used for inheritance (applied to newly created
>file objects in the directory), if I understand it correctly.

The document says "objects" .  I assumed that included directories.

>Again, since there is no way to have two NFSv4 ACLs associated with
>a directory, it is impossible to express this case via NFSv4 ACLs.

You can but there is some work to do.  the ACEs in the default acl can be
turned into inherit-only ACEs in a NFSv4 ACL.   The big issue is that
inheritance support is optional and there is no way to determine if  it is
supported.  I am fixing the latter in acls-02,

>
>> When and if this written up, that kind of think willl need to be
explained.  According to the IESG, the explanation needs to be
>>understandable to people who don't understand what "NFS" stands for.   I
don't agree but there is no point in arguing about it.  In any case, it
>needs to be clear to people outside the POSIX cognoscenti.   You can ciib
from the withdrawn POSIX draft but you probably cannot reference >it.

>Yes. I'm not sure if you can even find the withdrawn POSIX draft. I
>found this (see the last statement);

 > I was the final technical editor of the document, and had the
> unpleasant task of requesting its withdrawl after the completion of
> Draft 17.

  > In the end, only SGI and IBM cared enough about it to continue
> working on it, IBM would not pay for travel, and twice in Poughkeepsie
> was all I could handle.

>  More to the point, standards development fell off of the list of
> important things for computer companies right about 1995, and the
> security effort fell victem to that.

 > There where a number of issues with the Draft itself that didn't
> help. It should have been five seperate efforts (ACLs, Audit,
> Capabilities, Information Labels, MAC)
> rather that a single integrated document. The source for the draft
> disappeared for a year and was only partially recovered.
>Some sections where too ambitious for their intended purpose. Too
>much was designed by the working group.

>However, the Eriksen, Fields draft does do a nice job of describing it
>and I'd guess cribbing
> that should be ok (it has a "Copyright The Internet Society" on it).?

That makes sense but there are going to be point of detail that it doesn't
resolve so we will need tesrt n existing impementations.
>
> >which are both RW, per file attributes.
>
> > I would not allow any given file to support both the "acl" and
> > "posix_access_acl/posix_default_acl" attributes.
>
>> Why not?   How would a file system decide which of those was supported
once a file was created?
>> For FreeBSD, it is done via an option at mount time of the server file
>>system. The ACLs are stored on the file object as extended
>>attributes in the system name space. If the file system is mounted
>> with the "acls" option, the NFSv4 ACL
>> is ignored (it is just an extended attribute). If the file system is
>>mounted with the "nfsv4acls" option, then
>> the POSIX draft ACL is ignored (it is just an extended attribute).
>Although it is conceivable that a server could flip back and forth
>between the two types,

Not conceivable to me.

>I do not see why
that needs to be allowed?
>There could be something stated, where which type is supported cannot
>change while any client holds a
>clientID for the server. (ie. a server reboot forcing a new ExchangeID
>would be required when the type of
>ACL supported for a file is to change).

Sounds messy.

>Since they are not semantically compatible, I do not know how a server
> could handle both
> concurrently for a file?

Given how small the incompatibilities are the efforts made by the working
group to harmonize (well-intentioned but quite effective), I think we will
be better off with hardmonization.

I any case, there will be NFSv4 ACLs so there will be an error if you
interrogate the posix-acl attribute and the acl is not expresssible.

The reverse case in which a posix cannot be represented would also need
such an error but for file systems, that supported the
no-partial-allow-ace-satisfaction bit in aclchoice, that error  would never
happen.

On Wed, Jun 12, 2024 at 4:51 PM Rick Macklem <[e-mail]> wrote:

> On Wed, Jun 12, 2024 at 10:35 AM David Noveck <[e-mail]>
> wrote:
> >
> > > Just fyi, I prototyped a POSIX draft (or UNIX) ACL implementation on
> FreeBSD and
> > > it seems to work ok.
> >
> > > Here's the XDR for what I prototyped:
> > >
> > >enum acetag4 {
> >  >       POSIXACE4_TAG_USER_OBJ     = 1,
> >  >       POSIXACE4_TAG_USER         = 2,
> >  >       POSIXACE4_TAG_GROUP_OBJ    = 3,
> >  >       POSIXACE4_TAG_GROUP        = 4,
> >  >        POSIXACE4_TAG_MASK         = 5,
> >
> > I have no idea what this does.
> Sec. 3 of the Eriksen, Fields draft gives you a very nice description of
> them.
> (Better than I could write.) It's still in the datatracker and I think
> you could crib it?
>
>  https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-acl-mapping-05
>
> Btw, Sec. 5 of this draft shows you the case where a POSIX draft ACL
> cannot be expressed as a NFSv4 ACL. The existence of this case is one
> reason why I think separate attributes for POSIX draft ACLs is appropriate.
> (The other is the default ACL. See the end of Sec. 3 of the draft and
> below.)
>
> >
> >  >        POSIXACE4_TAG_OTHER        = 6
> >
> > Currently, NFSv4 has EVERYONE@.   OTHERS@ would be a help and could be
> added in v4.2.   I don't think it could be added in v4.1, but perhaps a
> case or it could be made.
> Without the rest of the POSIX draft ACL stuff, I do know if this would
> be useful?
> >
> > > };
> >
> > > typedef uint32_t        aceperm4;
> >
> > /* Bit definitions for aceperm4. */
> > > const POSIXACL4_PERM_EXECUTE    = 0x00000001;
> > > const POSIXACL4_PERM_WRITE      = 0x00000002;
> > > const POSIXACL4_PERM_READ       = 0x00000004;
> >
> > >struct posixace4 {
> > >        acetag4         tag;
> > >        aceperm4        perm;
> > >        utf8str_mixed   who;
> > > };
> >
> > > And I defined two new attributes:
> >
> > > posix_access_acl      posixace4<>;
> > > posix_default_acl     posixace4<>;
> >
> > Is there a reference that explains default_acl.?
> The end of Sec. 3 of the Eriksen, Fields draft.
> Basically, directories can have both an access and default ACL.
> The default ACL is only used for inheritance (applied to newly created
> file objects in the directory), if I understand it correctly.
>
> Again, since there is no way to have two NFSv4 ACLs associated with
> a directory, it is impossible to express this case via NFSv4 ACLs.
>
> >
> > When and if this written up, that kind of think willl need to be
> explained.  According to the IESG, the explanation needs to be
> understandable to people who don't understand what "NFS" stands for.   I
> don't agree but there is no point in arguing about it.  In any case, it
> needs to be clear to people outside the POSIX cognoscenti.   You can ciib
> from the withdrawn POSIX draft but you probably cannot reference it.
>
> Yes. I'm not sure if you can even find the withdrawn POSIX draft. I
> found this (see the last statement);
>
>   I was the final technical editor of the document, and had the
> unpleasant task of requesting its withdrawl after the completion of
> Draft 17.
>
>   In the end, only SGI and IBM cared enough about it to continue
> working on it, IBM would not pay for travel, and twice in Poughkeepsie
> was all I could handle.
>
>   More to the point, standards development fell off of the list of
> important things for computer companies right about 1995, and the
> security effort fell victem to that.
>
>   There where a number of issues with the Draft itself that didn't
> help. It should have been five seperate efforts (ACLs, Audit,
> Capabilities, Information Labels, MAC)
>    rather that a single integrated document. The source for the draft
> disappeared for a year and was only partially recovered.
>    Some sections where too ambitious for their intended purpose. Too
> much was designed by the working group.
>
> However, the Eriksen, Fields draft does do a nice job of describing it
> and I'd guess cribbing
> that should be ok (it has a "Copyright The Internet Society" on it).?
>
> >
> > >which are both RW, per file attributes.
> >
> > > I would not allow any given file to support both the "acl" and
> > > "posix_access_acl/posix_default_acl" attributes.
> >
> > Why not?   How would a file system decide which of those was supported
> once a file was created?
> For FreeBSD, it is done via an option at mount time of the server file
> system. The ACLs are stored on the file object as extended
> attributes in the system name space. If the file system is mounted
> with the "acls" option, the NFSv4 ACL
> is ignored (it is just an extended attribute). If the file system is
> mounted with the "nfsv4acls" option, then
> the POSIX draft ACL is ignored (it is just an extended attribute).
> Although it is conceivable that a server could flip back and forth
> between the two types, I do not see why
> that needs to be allowed?
> There could be something stated, where which type is supported cannot
> change while any client holds a
> clientID for the server. (ie. a server reboot forcing a new ExchangeID
> would be required when the type of
> ACL supported for a file is to change).
>
> Since they are not semantically compatible, I do not know how a server
> could handle both
> concurrently for a file?
> >
> > Are you somehow assuming that once one of these options was taken the
> other would not be supported
> > by the other.   That seems to me a misuse of the term "supported".
> Consider what supported_ttrs would return.
> Well, when I prototyped it, the file's supported_attrs attribute
> either includes the bits for the acl and aclsupport
> attributes or the bits for posix_access_acl and posix_default_acl
> attributes, but never an intersection of these
> two sets of bits.
>
> >
> > It also might be preferable to specify that it be one or the other
> > on a per file system basis.
> >
> > That doesn't sound good to me either.   If you have two acl attributes,
> it should be possible to support both.
> Then how do you define the semantics. You could say that access is
> only allowed when both ACLs allow it,
> but that would be just more confusing, I think. I believe it is
> simpler to define it as one or the other.
>
> >
> > I think we need to wait for feedback from others before proceeding
> further.
> Trond sent me email offlist which said he was busy, but would try to
> post in a few days. Since Chuck
> deferred this to Trond (and the other Linux folk won't be interested
> unless Trond is interested), this
> was really "I am waiting for Trond's email".
>
> >
> > My feedback is above.   I think you need to be clearer about the
> semantics of what you are proposing.
> If Trond is supportive of the suggestion, I can write up another
> draft, cribbing the Eriksen, Fields one for
> POSIX draft semantics (I'll ask Bruce first, and Marius if I can get
> his current email) and will include a
> clarification on why I do not think concurrent use of both kinds of
> ACLs is a good idea.
>
> rick
>
> >
> > rick
> > ps: I have no burning desire to write this up, but if no one else is
> interested,
> >       I can take a stab at it.
> >
> > If you do, I would be interested in seeing it.
> >
> > >To clarify this, I was thinking of the FreeBSD UFS case where both
> > > types of ACLs could be stored on the same file in the server.
> >
> > OK.  You also mention that you can flip approaches on reboot.  If that
> is the case:
> >
> > I want to understand the mapping.
> > See if it is possible to make sure that the acls document is consistent
> with it.
> >
> > >I was not thinking of the case, such as a Linux server, where the one
> > >ACL is accessed/modified using both types of attributes.
> >
> > I think that is a case that needs to be considered.
> >
> > On Tue, Jun 11, 2024 at 10:26 AM Rick Macklem <[e-mail]>
> wrote:
> >>
> >> On Mon, Jun 10, 2024 at 8:05 PM Rick Macklem <[e-mail]>
> wrote:
> >> >
> >> > On Fri, Jun 7, 2024 at 1:48 PM David Noveck <[e-mail]>
> wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Fri, Jun 7, 2024, 11:20 AM Chuck Lever III <chuck.lever=
> [e-mail]> wrote:
> >> > >>
> >> > >>
> >> > >>
> >> > >> > On Jun 6, 2024, at 6:57 PM, Jeff Layton <[e-mail]>
> wrote:
> >> > >> >
> >> > >> > On Wed, 2024-06-05 at 12:47 -0700, Rick Macklem wrote:
> >> > >> >> On Wed, Jun 5, 2024 at 8:56 AM Jeff Layton <
> [e-mail]>
> >> > >> >> wrote:
> >> > >> >>>
> >> > >> >>> On Mon, 2024-06-03 at 16:50 -0700, Rick Macklem wrote:
> >> > >> >>>> On Sun, Jun 2, 2024 at 6:47 PM Rick Macklem
> >> > >> >>>> <[e-mail]>
> >> > >> >>>> wrote:
> >> > >> >>>>>
> >> > >> >>>>> On Sun, Jun 2, 2024 at 4:36 PM David Noveck
> >> > >> >>>>> <[e-mail]>
> >> > >> >>>>> wrote:
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> On Sun, Jun 2, 2024, 4:35 PM Rick Macklem
> >> > >> >>>>>> <[e-mail]> wrote:
> >> > >> >>>>>>>
> >> > >> >>>>>>> On Sun, Jun 2, 2024 at 4:50 AM David Noveck
> >> > >> >>>>>>> <[e-mail]> wrote:
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> On Saturday, June 1, 2024, Rick Macklem
> >> > >> >>>>>>>> <[e-mail]> wrote:
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> On Fri, Apr 26, 2024 at 11:17 AM David Noveck
> >> > >> >>>>>>>>> <[e-mail]> wrote:
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> I've just posted the new draftof the acls doc, split
> >> > >> >>>>>>>>>> out
> >> > >> >>>>>>>>>> from security as suggested during previous working
> >> > >> >>>>>>>>>> group
> >> > >> >>>>>>>>>> discussions.   For summary information on this
> >> > >> >>>>>>>>>> document,
> >> > >> >>>>>>>>>> see slides 11-15 of the attached slide deck.
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> At the recent interim meeting, both Chris and Tom H
> >> > >> >>>>>>>>>> suggested that it would be good, at this point, to
> >> > >> >>>>>>>>>> get
> >> > >> >>>>>>>>>> people's opinions about the best way to proceed
> >> > >> >>>>>>>>>> forward
> >> > >> >>>>>>>>>> in dealing with ACLs.  I agree that this is a good
> >> > >> >>>>>>>>>> idea
> >> > >> >>>>>>>>>> and join with them in asking people to contribute
> >> > >> >>>>>>>>>> their
> >> > >> >>>>>>>>>> views.
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> I've already provided my own outline of a set of
> >> > >> >>>>>>>>>> suggestions regarding ways forward in slides 21-24 of
> >> > >> >>>>>>>>>> the
> >> > >> >>>>>>>>>> attached slide deck.  My updated response will be two
> >> > >> >>>>>>>>>> parts:
> >> > >> >>>>>>>>>>
> >> > >> >>>>>>>>>> As the preliminary step in the process: Read The
> >> > >> >>>>>>>>>> Fabulous
> >> > >> >>>>>>>>>> Draft :-)
> >> > >> >>>>>>>>>> I'll be sending out updated suggestions regarding the
> >> > >> >>>>>>>>>> choice of ways forward in the next few days.   While,
> >> > >> >>>>>>>>>> broadly speaking, this is consistent with what is in
> >> > >> >>>>>>>>>> the
> >> > >> >>>>>>>>>> slide deck, there are changes beyond those involved
> >> > >> >>>>>>>>>> in
> >> > >> >>>>>>>>>> presenting these ideas in a non-powerpunctual way,
> >> > >> >>>>>>>>>> e.g.
> >> > >> >>>>>>>>>> by writing coherent paragraphs.
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> I have been working through the draft slowly and beyond
> >> > >> >>>>>>>>> the
> >> > >> >>>>>>>>> proposed
> >> > >> >>>>>>>>> ACLFeatures attribute,
> >> > >> >>>>>>>>> I do not see how this resolved the problem for the
> >> > >> >>>>>>>>> POSIX
> >> > >> >>>>>>>>> draft ACL
> >> > >> >>>>>>>>> folk (aka Linux). The
> >> > >> >>>>>>>>> draft talks about how this is working to resolve the
> >> > >> >>>>>>>>> POSIX-
> >> > >> >>>>>>>>> draft vs
> >> > >> >>>>>>>>> NFSv4 ACL situation.
> >> > >> >>>>>>>>> David, maybe you can point out where to look in the
> >> > >> >>>>>>>>> draft
> >> > >> >>>>>>>>> to understand this?
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> There have been some changes in plans that I discussed at
> >> > >> >>>>>>>> the
> >> > >> >>>>>>>> 5/21 interim meeting.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> To quickly summarize:
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> I discovered that Section 9 of RFC8178 allow limited so
> >> > >> >>>>>>>> that
> >> > >> >>>>>>>> I am planning in acls-02, of taking advantage of that, by
> >> > >> >>>>>>>> add
> >> > >> >>>>>>>> an optional aclchoice attribute, much simpler than
> >> > >> >>>>>>>> ACLFeature
> >> > >> >>>>>>>> to v4.1, rather than waiting for v4.2.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> The current target date for acls-02: is 6/20.
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> I do not know if it has already been discussed, but has
> >> > >> >>>>>>>>> revisiting
> >> > >> >>>>>>>>> this decision been considered?
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> It was discussed early on.  The response was quite
> >> > >> >>>>>>>> negative
> >> > >> >>>>>>>> (it seemed people didn't want to hear about it) so I
> >> > >> >>>>>>>> dropped
> >> > >> >>>>>>>> it.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>> *  Defining support for the two types of ACLs by means
> >> > >> >>>>>>>>> of
> >> > >> >>>>>>>>> two
> >> > >> >>>>>>>>>       separate attributes.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> I personally think this is a good idea but I think it is
> >> > >> >>>>>>>> too
> >> > >> >>>>>>>> big to do in v4.1 but would require a v4.2 extension.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>>
> >> > >> >>>>>>>>>    *  Providing the client other means (e.g. a per-fs
> >> > >> >>>>>>>>> read-
> >> > >> >>>>>>>>> only OPTIONAL
> >> > >> >>>>>>>>>       attribute) by which the client can determine
> >> > >> >>>>>>>>> which
> >> > >> >>>>>>>>> semantic model
> >> > >> >>>>>>>>>       was implemented.
> >> > >> >>>>>>>>
> >> > >> >>>>>>>>
> >> > >> >>>>>>>> That is pretty close to what aclchoice turns out to be
> >> > >> >>>>>>>> for
> >> > >> >>>>>>>> those providing the UNIX acl model.  Those providing the
> >> > >> >>>>>>>> nfsv4 model or a hybrid would need to make few more
> >> > >> >>>>>>>> choices
> >> > >> >>>>>>>> about what extensions they do support.
> >> > >> >>>>>>> So, is the plan to have an "inverse algorithm"
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> Almost certainly not since I have no idea what you are
> >> > >> >>>>>> talking
> >> > >> >>>>>> about.  Sigh!
> >> > >> >>>>> I was referring to...
> >> > >> >>>>> f(X) -> Y
> >> > >> >>>>> f'(Y) -> X
> >> > >> >>>>> the f'() { or f-prime } function that  generates X given Y,
> if
> >> > >> >>>>> f(X)
> >> > >> >>>>> is
> >> > >> >>>>> the basic function.
> >> > >> >>>>> (Sorry, my math from the 1970s has just gone away, so I
> cannot
> >> > >> >>>>> remember what the
> >> > >> >>>>> term for f'(Y) is, given f(X).)
> >> > >> >>>>>
> >> > >> >>>>>>
> >> > >> >>>>>>> (for want of a better
> >> > >> >>>>>>> term)
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> The particular term is not the problem.
> >> > >> >>>>>>
> >> > >> >>>>>>> that the
> >> > >> >>>>>>>
> >> > >> >>>>>>> client can use to generate a NFSv4 ACL that translates
> >> > >> >>>>>>> cleanly
> >> > >> >>>>>>> to a UNIX
> >> > >> >>>>>>> ACL.
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> The specification should provide enough information for a
> >> > >> >>>>>> client
> >> > >> >>>>>> to generate the ACL in this case.  Is that what you are
> >> > >> >>>>>> looking
> >> > >> >>>>>> for?
> >> > >> >>>>> I am looking for f'(Y), so that the FreeBSD client can
> generate
> >> > >> >>>>> a
> >> > >> >>>>> NFSv4 ACL to put on the wire, such that it gets translated
> back
> >> > >> >>>>> to the same UNIX ACL that the FreeBSD client wanted to set.
> >> > >> >>>>>
> >> > >> >>>>>>
> >> > >> >>>>>>> when the Linux function nfs4_acl_nfsv4_to_posix() is
> >> > >> >>>>>>> applied to
> >> > >> >>>>>>> it?
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> I suppose so although I am just guessing about that
> function.
> >> > >> >>>>>>
> >> > >> >>>>>>>
> >> > >> >>>>>>> If such an algorithm exists (I cannot recall if I have ever
> >> > >> >>>>>>> heard of
> >> > >> >>>>>>> one?), .
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> If it doesn't, one can be written.
> >> > >> >>>>>>
> >> > >> >>>>>>> a client
> >> > >> >>>>>>> could use an attribute to indicate the server is following
> >> > >> >>>>>>> the
> >> > >> >>>>>>> UNIX acl model
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> That is probably not needed since, in NFSv4, the UNIX ACL
> >> > >> >>>>>> model
> >> > >> >>>>>> is embedded in the full NFSv4 ACL model, i.e. every UNIX ACL
> >> > >> >>>>>> is
> >> > >> >>>>>> an NFSv4 ACL but the reverse is not the case.
> >> > >> >>>>>>
> >> > >> >>>>>>> to
> >> > >> >>>>>>> enable use of such an algorithm to convert a UNIX acl to a
> >> > >> >>>>>>> NFSv4 ACL to go
> >> > >> >>>>>>> on the wire
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> Yes.
> >> > >> >>>>>>
> >> > >> >>>>>>> (and see the same ACL in a Getattr/ACL done against such a
> >> > >> >>>>>>> server).
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> Probably not exactly.  For example, a client that does not
> >> > >> >>>>>> support the mask bits that are finer-grained correlates of
> >> > >> >>>>>> the
> >> > >> >>>>>> write privilege bits may see these in the acls that come
> back
> >> > >> >>>>>> from serves that do support these.  Acls-02 will be clear a
> >> > >> >>>>>> out
> >> > >> >>>>>> the possible need to mask these out.
> >> > >> >>>>> The case I was trying to solve via GetPosixACL/SetPosixACL
> >> > >> >>>>> would be
> >> > >> >>>>> UNIX ACLs, not ones using other
> >> > >> >>>>> flags or finer granularity.
> >> > >> >>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> Another problem is the orphan mask bits which don't fit in
> >> > >> >>>>>> the
> >> > >> >>>>>> varying-granukarity model.  There are more complexities with
> >> > >> >>>>>> regard to these but it will be possible to mask these out
> for
> >> > >> >>>>>> ACLs that are within the UNIX semantic model.
> >> > >> >>>>>>>
> >> > >> >>>>>>>
> >> > >> >>>>>>> I do not think the Linux client does this at this time. I
> >> > >> >>>>>>> have
> >> > >> >>>>>>> assumed
> >> > >> >>>>>>> (quite possibly
> >> > >> >>>>>>> incorrectly) that the "inverse algorithm" did not exist.
> >> > >> >>>>>>> All I can see (I'm an not conversant with the Linux
> >> > >> >>>>>>> sources) is
> >> > >> >>>>>>> client
> >> > >> >>>>>>> side support
> >> > >> >>>>>>> for the NFSv3 ACL protocol.
> >> > >> >>>>>>
> >> > >> >>>>>>
> >> > >> >>>>>> That  doesn't sound right to me.  It  implies that there is
> >> > >> >>>>>> no
> >> > >> >>>>>> ACL support in NFSv4 Linux clients.  I don't think k that is
> >> > >> >>>>>> the
> >> > >> >>>>>> case.
> >> > >> >>>>> Well, the Linux client folk will need to answer this.
> >> > >> >>>> I tried a test with the Linux client NFSv4 mounting a FreeBSD
> >> > >> >>>> server
> >> > >> >>>> and all I saw
> >> > >> >>>> on the wire were Getattrs for things like "mode". I never saw
> a
> >> > >> >>>> Getattr for "acl" when
> >> > >> >>>> I did getfacl on the Linux client.  Setfacl on the Linux
> client
> >> > >> >>>> failed
> >> > >> >>>> with "operation not supported",
> >> > >> >>>> although there was no such error reply from the FreeBSD
> server,
> >> > >> >>>> on
> >> > >> >>>> the
> >> > >> >>>> wire (and there was no
> >> > >> >>>> Setattr operation on the wire, either).
> >> > >> >>>
> >> > >> >>>
> >> > >> >>> That's expected. The NFSv4 client does not present POSIX ACLs
> to
> >> > >> >>> userland. You need nfs4_get/setfacl for to see the v4 ACLs.
> >> > >> >>>
> >> > >> >>>>
> >> > >> >>>> There is Linux kernel client support for the NFSv3 NFSACL
> >> > >> >>>> sideband
> >> > >> >>>> protocol for NFSv3,
> >> > >> >>>> but FreeBSD does not support that.
> >> > >> >>>>
> >> > >> >>>> And, as I noted before, there are separate userspace commands
> >> > >> >>>> (not
> >> > >> >>>> usually in the distros)
> >> > >> >>>> nfs4_getfacl/nfs4_setfacl available as open source (used to be
> >> > >> >>>> maintained by Bruce Fields).
> >> > >> >>>> They do not build easily for the Linux system I have, so I
> have
> >> > >> >>>> not
> >> > >> >>>> tried them, but I would assume
> >> > >> >>>> similar results to what I get with the FreeBSD client. (See
> >> > >> >>>> below.)
> >> > >> >>>>
> >> > >> >>>
> >> > >> >>> This is shipped in fedora in the nfs4-acl-tools package, if
> you're
> >> > >> >>> using that. Other distros probably ship the same package.
> >> > >> >>>
> >> > >> >>> FWIW: there is this document too from Bruce several years ago,
> >> > >> >>> which
> >> > >> >>> lays out the "rules". We could resurrect that if it's helpful:
> >> > >> >>>
> >> > >> >>>
> >> > >> >>>
> https://datatracker.ietf.org/doc/html/draft-ietf-nfsv4-acl-mapping-05
> >> > >> >> Thanks Jeff. This clears things up nicely for me. It does
> specify an
> >> > >> >> algorithm
> >> > >> >> and notes the one case where a UNIX ACL->NFSv4 ACL mapping
> cannot be
> >> > >> >> done.
> >> > >> >>
> >> > >> >> For me, it is either:
> >> > >> >> a) - implement the UNIX ACL->NFSv4 ACL algorithm in the
> >> > >> >>       above document
> >> > >> >> or
> >> > >> >> b) -  define an extension to NFSv4.2 which includes operations
> >> > >> >>         to get/set UNIX ACLs (GetPosixACL/SetPosixACL or
> whatever
> >> > >> >> they
> >> > >> >> get called)
> >> > >> >>
> >> > >> >> Understandably David is not interested in b), but I will wait
> to see
> >> > >> >> what others think.
> >> > >> >> (I think it would be nice if some of the above draft could be
> >> > >> >> captured
> >> > >> >> in David's draft,
> >> > >> >>  but I understand if that is not practicable.)
> >> > >> >>
> >> > >> >> rick
> >> > >> >> ps: I will look at David's next draft, to see how it correlates
> with
> >> > >> >> what OpenZFS currently
> >> > >> >>       implements.
> >> > >> >>
> >> > >> >
> >> > >> >
> >> > >> > FWIW, I'd love to see POSIX ACL extensions for v4, as would most
> Linux
> >> > >> > NFSv4 users.
> >> > >> >
> >> > >> > Given that v4 ACLs are implemented as file attributes, I'd
> probably
> >> > >> > suggest not defining new operations, but instead defining an
> optional
> >> > >> > POSIX ACL file attribute that is settable. Something like
> section 6.2.1
> >> > >> > in RFC8881, but that mirrors draft POSIX ACLs.
> >> > >>
> >> > >> A new fattr4 attribute for accessing Posix ACLs would be nifty.
> >> > >
> >> > >
> >> > > Agree.
> >> > >>
> >> > >>
> >> > >>
> >> > >> > Servers that are exporting filesystems that natively support
> POSIX ACLs
> >> > >> > can then offer that attribute to clients and users could once
> again use
> >> > >> > "standard" getfacl/setfacl tools to deal with them.
> >> > >>
> >> > >> Interoperability with NFSv4 access control, or with servers
> >> > >> that support only NFSv4 ACLs, might still be complicated.
> >> > >
> >> > >
> >> > > Complicated is OK but impossible is not.  Although I will not be
> able to reference this in the current document, with the aclchoices
> attribute supported you would be able to do the determine the mapping
> necessary and decide when it is essentially the identity.
> >> > >
> >> > >>
> >> > >>
> >> > >> > I understand David not wanting to take on more scope creep
> though.
> >> > >> > Maybe we should consider it as a separate document / project?
> >> > >>
> >> > >> It would have to be an extension to NFSv4.2, by current rules.
> >> > Just fyi, I prototyped a POSIX draft (or UNIX) ACL implementation on
> FreeBSD and
> >> > it seems to work ok.
> >> >
> >> > Here's the XDR for what I prototyped:
> >> >
> >> > enum acetag4 {
> >> >         POSIXACE4_TAG_USER_OBJ     = 1,
> >> >         POSIXACE4_TAG_USER         = 2,
> >> >         POSIXACE4_TAG_GROUP_OBJ    = 3,
> >> >         POSIXACE4_TAG_GROUP        = 4,
> >> >         POSIXACE4_TAG_MASK         = 5,
> >> >         POSIXACE4_TAG_OTHER        = 6
> >> > };
> >> >
> >> > typedef uint32_t        aceperm4;
> >> >
> >> > /* Bit definitions for aceperm4. */
> >> > const POSIXACL4_PERM_EXECUTE    = 0x00000001;
> >> > const POSIXACL4_PERM_WRITE      = 0x00000002;
> >> > const POSIXACL4_PERM_READ       = 0x00000004;
> >> >
> >> > struct posixace4 {
> >> >         acetag4         tag;
> >> >         aceperm4        perm;
> >> >         utf8str_mixed   who;
> >> > };
> >> >
> >> > And I defined two new attributes:
> >> >
> >> > posix_access_acl      posixace4<>;
> >> > posix_default_acl     posixace4<>;
> >> >
> >> > which are both RW, per file attributes.
> >> > I would not allow any given file to support both the "acl" and
> >> > "posix_access_acl/posix_default_acl" attributes.
> >> > It also might be preferable to specify that it be one or the other
> >> > on a per file system basis.
> >> To clarify this, I was thinking of the FreeBSD UFS case where both
> >> types of ACLs could be stored on the same file in the server.
> >> I was not thinking of the case, such as a Linux server, where the one
> >> ACL is accessed/modified using both types of attributes.
> >>
> >> rick
> >>
> >> >
> >> > I have not tried seeing what happens if some files on the server's
> file
> >> > system have the POSIX draft ACLs and others NFSv4 ACLs.
> >> > (UFS allows you to flip flop between the two types of ACLs when you
> >> > reboot.)
> >> >
> >> > I think we need to wait for feedback from others before proceeding
> further.
> >> >
> >> > rick
> >> > ps: I have no burning desire to write this up, but if no one else is
> interested,
> >> >       I can take a stab at it.
> >> > >
> >> > >
> >> > > Yes.   The documents could be developed at the same time but I
> think I think it would be a problem to submit the extension to the IESG
> first, given that acl document is supposed to be  nfsv4-wide.
> >> > >
> >> > > I think what will happen is that there will need to be a small
> update of the ACL document once the extension document is published.
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Chuck Lever
> >> > >>
> >> > >>
> >> > >> _______________________________________________
> >> > >> nfsv4 mailing list -- [e-mail]
> >> > >> To unsubscribe send an email to [e-mail]
> >> > >
> >> > > _______________________________________________
> >> > > nfsv4 mailing list -- [e-mail]
> >> > > To unsubscribe send an email to [e-mail]
>