orangefs: posix acl fix...
authorMike Marshall <hubcap@omnibond.com>
Thu, 9 Jul 2020 19:02:32 +0000 (15:02 -0400)
committerMike Marshall <hubcap@omnibond.com>
Tue, 28 Jul 2020 16:52:53 +0000 (12:52 -0400)
commit476af91933ce81d534761d31382459f6e9eb6c6d
treeb8ffb653357246f171ad4534f4c5fdebd2a8feb5
parent92ed301919932f777713b9172e525674157e983d
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>
fs/orangefs/acl.c