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

[Ondrej Valousek]

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


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

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

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

> 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.
Having the bug above opened, I think it's perhaps better to fix Linux kernel 
NFSd rather than putting extra code here.

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.

What do you think?
Ondrej