summaryrefslogtreecommitdiff
path: root/include/linux/overflow.h
diff options
context:
space:
mode:
authorMike Marshall <hubcap@omnibond.com>2020-07-09 15:02:32 -0400
committerMike Marshall <hubcap@omnibond.com>2020-07-28 12:52:53 -0400
commit476af91933ce81d534761d31382459f6e9eb6c6d (patch)
treeb8ffb653357246f171ad4534f4c5fdebd2a8feb5 /include/linux/overflow.h
parent92ed301919932f777713b9172e525674157e983d (diff)
orangefs: posix acl fix...
Al Viro pointed out that I broke some acl functionality... * ACLs could not be fully removed * posix_acl_chmod would be called while the old ACL was still cached * new mode propagated to orangefs server before ACL. ... when I tried to make sure that modes that got changed as a result of ACL-sets would be sent back to the orangefs server. Not wanting to try and change the code without having some cases to test it with, I began to hunt for setfacl examples that were expressible in pure mode. Along the way I found examples like the following which confused me: user A had a file (/home/A/asdf) with mode 740 user B was in user A's group user C was not in user A's group setfacl -m u:C:rwx /home/A/asdf The above setfacl caused ls -l /home/A/asdf to show a mode of 770, making it appear that all users in user A's group now had full access to /home/A/asdf, however, user B still only had read acces. Madness. Anywho, I finally found that the above (whacky as it is) appears to be "posixly on purpose" and explained in acl(5): If the ACL has an ACL_MASK entry, the group permissions correspond to the permissions of the ACL_MASK entry. Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Diffstat (limited to 'include/linux/overflow.h')
0 files changed, 0 insertions, 0 deletions