Re: [PATCH] Basic support for checking NFSv4 ACLs in Linux

[Andreas Grünbacher]

Am Do., 10. Nov. 2022 um 14:43 Uhr schrieb Ondrej Valousek
<ondrej.valousek.xm@renesas.com>:
> Hi Andreas,
>
> > this doesn't belong on the acl-devel mailing list; may I suggest the 
> > coreutils@gnu.org list instead?
> Yes sorry I realized it after I hit the send button

[... and yet we're still discussing this on acl-devel ...]

> > Something similar to that probably, yes. Now the remaining loophole is that 
> > what you're getting here is the over-the-wire value of an NVSv4 ACL. 
> > Servers can implement any kind of ACL scheme, and so having less than three 
> > ACL entries doesn't guarantee that the resulting ACL is already truthfully 
> > represented by the file mode. For example, the ACL can grant permissions 
> > that go beyond what the file mode can grant, like the permission to change 
> > permissions.
>
> I understand that - that's eventually the purpose of ACLs, but from my 
> understanding and experiments with various NFS servers, the 3 basic ACL rules 
> representing the file mode are always present. So we always get at least 3 
> ACEs, not less.

But nothing guarantees that, and servers not based on the UNIX
permission model are very unlikely to always return those three
entries. What we know is that no reasonable server will ever convert
the file mode permission bits into more than five entries, though.

> > Beyond that, the file mode permission bits could also be set to something 
> > like r---w-rw-. In that case, a matching NFSv4 ACL could contain something 
> > the following entries:
>
> 1 - Grant the owner Read access.
> 2 - Deny the owning group read access.
> 3 - Grant the owning group Write access.
> 4 - Grant everyone Read and Write access.

Ah, I actually got the example wrong; there also needs to be a "Deny
the owner write access" entry at the beginning.

> Here (using your example with r---w-rw-)  the Linux NFS server behavior is 
> substantially different to Netapp, with Linux nfs server, I got 5 ACEs but 
> Netapp still represents 3 ACEs (Netapp):
>
> # file: dokuwiki-stable.tgz
> A::OWNER@:rtncCy
> A:g:GROUP@:watTNcy
> A::EVERYONE@:rwatTnNcy
>
> Vs (Linux):
> # file: test
> D::OWNER@:wa
> A::OWNER@:rtTcCy
> A::GROUP@:watcy
> D::GROUP@:r
> A::EVERYONE@:rwatcy

> My understanding both are right but Linux Deny rules are perhaps not needed - 
> as default rule is Deny. Also Linux kernel is actually presenting it 
> incorrectly, as 'g' flag is missing for group.

Hmm, I don't know if the g flag is actually required for SPECIAL@ ACL
entry owners. It probably isn't, but can you ask the Linux NFSv4 folks
that?

> Moreover Linux kernel Posix to NFS4 acl mapping seems to be utterly broken 
> (see https://bugzilla.redhat.com/show_bug.cgi?id=2136452) so I take that 
> Netapp is right here and my patch works fine with Netapp based NFSv4 server.

No, what Netapp returns is objectively wrong. The ACL says that
everyone including the owner and the owning group have rw access. But
with UNIX file permissions, the owner gets exactly the owner
permissions, the owning group gets exactly the owning group
permissions, and others get the other permissions. That's also why
it's called "other" instead of "everyone".

> > So reasonable and straight-forward representations of the file mode can 
> > have up to three Allow and two Deny entries, for the owner, the owning 
> > group, and for everyone else, the permissions in the Allow entries 
> > shouldn't go beyond what the file mode permission bits can express (Read, 
> > Write, Execute), and the CL entries don't contain any unexpected 
> > inheritance flags.
>
> Yes, but I can't see any simple way how to detect this in the GNULIB code. In 
> case of 4-5 ACEs presented, I would have to decode each ACE and check if the 
> 2 ones are not belonging to GROUP deny ACE.

Of course you'll have to look at the ACL entries. It's not all that
hard, though.

> Having the bug above opened, I think it's perhaps better to fix Linux kernel 
> NFSd rather than putting extra code here.

We actually only care about mapping the file mode permission bits to
an NFSv4 ACL as far as file_has_acl() is concerned. A bug in the POSIX
ACL to NFSv4 ACL mapping code is entirely independent of that.

> But if you think we need to have more solid code to detect the Deny ACEs 
> representing mode bits, then as I said, I see no quick & simple code to do 
> this directly in gnulib, we would probably have to do it (ideally) in libacl.

I've already told you that libacl doesn't do NFSv4 ACLs. It will
continue not to do them.

Historically, I've suggested taking care of these kinds of things in
the richacl project, but that effort has been shot down upstream, and
that project has been dead for a long time.

Thanks,
Andreas