summaryrefslogtreecommitdiffstats
path: root/fs/orangefs/orangefs-mod.c
diff options
context:
space:
mode:
authorMike Marshall <hubcap@omnibond.com>2020-07-09 21:02:32 +0200
committerMike Marshall <hubcap@omnibond.com>2020-07-28 18:52:53 +0200
commit476af91933ce81d534761d31382459f6e9eb6c6d (patch)
treeb8ffb653357246f171ad4534f4c5fdebd2a8feb5 /fs/orangefs/orangefs-mod.c
parentLinux 5.8-rc7 (diff)
downloadlinux-476af91933ce81d534761d31382459f6e9eb6c6d.tar.xz
linux-476af91933ce81d534761d31382459f6e9eb6c6d.zip
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 'fs/orangefs/orangefs-mod.c')
0 files changed, 0 insertions, 0 deletions