On Wed, Oct 30, 2024 at 5:19 AM Chuck Lever III <chuck.lever@xxxxxxxxxx> wrote:
>
>
>
> > On Oct 29, 2024, at 10:43 PM, Rick Macklem <rick.macklem@xxxxxxxxx> wrote:
> >
> > Hi,
> >
> > I've run into a rough patch (no pun intended;-) w.r.t. the server
> > side implementation of the POSIX draft ACL attribute extension.
> >
> > (N)VERIFY operations need to compare attributes for "equal" and
> > that is not easy.
> >
> > First, the current server code compares raw XDR and that will
> > only compare "equal" if the ACEs are in the exact same order
> > and all the "who" strings (which represent users and groups)
> > are in the exact same format.
> >
> > It would be a lot of work to rewrite VERIFY so that it does not
> > compare raw XDR and, even then, any difference in the way
> > the "who" strings are expressed on-the-wire vs what is generated
> > from the server's current ACL (a number in a string vs user@domain
> > for example) would be difficult to compare.
> >
> > To avoid this problem, I am considering not allowing the POSIX
> > draft ACLs to be used for (N)VERIFY operations in the Internet
> > Draft.
> >
> > Does this sound reasonable?
>
> IMHO you should ask the WG first.
I will ask the WG. I asked here first because it looks like it would
be a "royal pita" to re-write the knfsd VERIFY/NVERIFY support
to make the POSIX draft ACL attributes work.
Maybe I should word it as...
"Does anyone see a big problem with not allowing the POSIX draft
ACL attributes to be used by VERIFY/NVERIFY?"
> Would NFSv4 ACLs have the same
> issues?
The first "who" issue, yes. (It also applies to Owner/Owner_group.)
I see two ways (N)VERIFY can compare the who values "same".
A) - Require the string to be identical.
or
B) - Require the string to map to the same user/group (uid/gid
for POSIX like servers).
Right now, it appears the Linux knfsd does A) and the FreeBSD
server does B).
Which is correct?
I have no idea, since the RFCs do not seem to discuss this.
--> This is definitely one for the WG.
The ACE order issue, I'd say no. When ACEs in a NFSv4
ACL are reordered, the access semantics changes.
(This in not true for POSIX draft ACLs, although Linux
chooses to sort them based on tag and id. See sort_pacl()
in fs/nfsd/nfs4acl.c and posix_acl_valid() in fs/posix_acl.c.)
--> Neither the withdrawn draft nor Grunbacher paper specifies
an ACE ordering. This is done internally for Linux to simplify
the implementation of access checking, from what I can see.
I will post about both of these on nfsv4@xxxxxxxx, in case anyone
is interested.
rick
>
> --
> Chuck Lever
>
>
