Apparent incorrect behaviour in NFSv4 ACL processing in 11.1-REL. Expected/correct behaviour or bug?

[Stilez Stilezy]

I've managed to get reproducible behaviour on FreeBSD 11.1, showing that in
some cases:

1) an NFSv4 ACE that shouldn't affect the access granted to an account,
does seem to affect it; and
2) this behaviour can be worked around by giving the account "ra" instead
or "r" even though from docs, "a" shouldn't be relevant to the access
affected.

It looks like a bug to me, but perhaps there's some non-bug explanation for
it, or it's my lack of knowledge?

Test output follows below.

I've interspersed commands/output from two parallel sessions, one (#)
privileged, the other (%) unprivileged. Comments are in ALL-CAPS.

Any light on what's going on would be appreciated - thanks.

Stilez.




COMMENT: CHECK MOUNT OPTIONS ARE NORMAL, AND SET UP A CLEAN TEST DIR +
CONTENTS

# mount | grep testpool
testpool on /mnt/testpool (zfs, local, noatime, nfsv4acls)
testpool/User_files on /mnt/testpool/User_files (zfs, local, noatime,
nfsv4acls)

# mkdir /mnt/testpool/test5; mkdir /mnt/testpool/test5/subdir; touch
/mnt/testpool/test5/subfile; ls -1F /mnt/testpool/test5
subfile
subdir/

COMMENT: CHECK OUR DIR IS READABLE WITH A NEWLY CREATED UNPRIVILEGED
ACCOUNT IN ANOTHER SSH WINDOW:

% ls /mnt/testpool/test5
subdir  subfile

COMMENT: QUICKLY SET UP SOME ACLS TO EXHIBIT THE BEHAVIOUR:
COMMENT: THESE ACLS SHOULD ALLOW THE UNPRIVILEGED ACCOUNT TO READ THE DIR
BUT NOTHING ELSE (AND THEY DO - SO FAR IT'S OK)

# setfacl -a 0 everyone@:r::allow,owner@::allow,group@::allow,everyone@::allow
/mnt/testpool/test5 ; \
  setfacl -x 4 /mnt/testpool/test5;  setfacl -x 4 /mnt/testpool/test5;
 setfacl -x 4 /mnt/testpool/test5; getfacl /mnt/testpool/test5
# file: /mnt/testpool/test5
# owner: root
# group: wheel
everyone@:r-------------:-------:allow
owner@:--------------:-------:allow
group@:--------------:-------:allow
everyone@:--------------:-------:allow

COMMENT: CHECK THAT OUR UNPRIVILEGED ACCOUNT CAN READ THE DIR AS EXPECTED,
AND ONLY NEEDS "r" TO DO SO:

% ls /mnt/testpool/test5
subdir  subfile

COMMENT: SO FAR ALL IS OK.
COMMENT: NOW ADD A SINGLE ACE THAT SHOULDN'T AFFECT OUR UNPRIVILEGED
ACCOUNT AT ALL
COMMENT: NOTHING SHOULD HAVE CHANGED FOR OUR UNPRIVILEGED ACCOUNT, BUT IT
NOW CANNOT READ THE DIR.

# setfacl -a 1 group:nogroup:rwxpDda-R-c---:fd-----:allow
/mnt/testpool/test5 ; getfacl /mnt/testpool/test5
# file: /mnt/testpool/test5
# owner: root
# group: wheel
everyone@:r-------------:-------:allow
group:nogroup:rwxpDda-R-c---:fd-----:allow
owner@:--------------:-------:allow
group@:--------------:-------:allow
everyone@:--------------:-------:allow

% ls /mnt/testpool/test5
ls: /mnt/testpool/test5: Permission denied

COMMENT: LET'S GIVE THE UNPRIVILEGED ACCOUNT 'ra' INSTEAD OF 'r'.
COMMENT: WITH "ra" IT CAN READ THE DIR AGAIN:

# setfacl -a 0 everyone@:ra::allow /mnt/testpool/test5 ; getfacl
/mnt/testpool/test5
# file: /mnt/testpool/test5
# owner: root
# group: wheel
everyone@:r-----a-------:-------:allow
everyone@:r-------------:-------:allow
group:nogroup:rwxpDda-R-c---:fd-----:allow
owner@:--------------:-------:allow
group@:--------------:-------:allow
everyone@:--------------:-------:allow

% ls /mnt/testpool/test5
subdir  subfile

COMMENT: CONFIRM THE "a" WAS NECESSARY, BY REMOVING IT.
COMMENT: THE UNPRIVILEGED ACCOUNT CAN NOT READ THE DIR WITHOUT "ra":

# setfacl -x 0 /mnt/testpool/test5 ; getfacl /mnt/testpool/test5
# file: /mnt/testpool/test5
# owner: root
# group: wheel
everyone@:r-------------:-------:allow
group:nogroup:rwxpDda-R-c---:fd-----:allow
owner@:--------------:-------:allow
group@:--------------:-------:allow
everyone@:--------------:-------:allow

% ls /mnt/testpool/test5
ls: /mnt/testpool/test5: Permission denied