[Bug 228538] [permissions] effective allow/deny ACLs incorrectly evaluated in some cases [reproducible]
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sun May 27 10:21:21 UTC 2018
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228538
Bug ID: 228538
Summary: [permissions] effective allow/deny ACLs incorrectly
evaluated in some cases [reproducible]
Product: Base System
Version: 11.1-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: bugs at FreeBSD.org
Reporter: stilezy at gmail.com
I've managed to get reproducible behaviour on FreeBSD 11.1-REL, showing that:
1) an NFSv4 ACE that shouldn't affect the access granted to an account, does
seem to affect it; and
2) giving the account "ra" instead or "r" rights bypasses the account's "read
directory content" denied access, even though "a" shouldn't be relevant to (or
change) the affected access.
Test output follows below.
I've interspersed commands/output from two parallel sessions, one (#)
privileged, the other (%) unprivileged.
Comments are in ALL-CAPS.
--------------
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
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list