On 8/21/2018 5:33 PM, J. Bruce Fields wrote:
In the wire protocol there's no need for such constants. An ACE can
have one of the special strings OWNER@, GROUP@, or EVERYONE@ in the
owner field, and that's all you need.
Ah, so an NFSv4 client is supposed to figure out whether or not it's a
special ACE just by the who_string... That probably explains why I
didn't see the same issue using the nfs4-acl-tools on a Linux client
mounting an illumos ZFS share via NFS.
The only use of those constants is probably internal to the ACL tools,
so they don't have to agree with any standards.
Ok, I found the illumos NFSv4 server code where it converts the local
ZFS ACLs to/from xdr format, and you're right, those flags are not
included in the outbound mapping, it converts them to the special entry
strings, and it does string comparisons to determine whether or not to
add them for the inbound mapping.
However, in the nfs4-acl-tools code it seems to expect those bits off
the wire to decode and is willing to send them on the wire?
For example, in libnfs4acl/nfs4_get_ace_flags.c
if (flags & NFS4_ACE_OWNER)
*buf++ = FLAG_OWNER_AT;
If it sees that bit set in the flags, it adds 'O' to the string
representation, and correspondingly in libnfs4acl/nfs4_ace_from_string.c:
case FLAG_OWNER_AT:
flags |= NFS4_ACE_OWNER;
break;
If you include O in your ACL specification, it will add that flag and
include it when it sends it? The same for the NFS4_ACE_GROUP and
NFS4_ACE_EVERYONE flags.
I'm confused why the nfs4-acl-tools would need these local defines. On
the ZFS side, the on-disk ACL format doesn't include strings, just flags
and uids/gids, so the extra flag bits are presumably needed so it can
tell which entries are special. However, the tools presumably are only
intended to consume NFSv4 xdr, and generate it? So why did they need
these flags given that the NFSv4 xdr format doesn't include them?
Thanks for the input, much appreciated…
