diff options
author | Mike Marshall <hubcap@omnibond.com> | 2020-07-09 22:02:32 +0300 |
---|---|---|
committer | Mike Marshall <hubcap@omnibond.com> | 2020-07-28 19:52:53 +0300 |
commit | 476af91933ce81d534761d31382459f6e9eb6c6d (patch) | |
tree | b8ffb653357246f171ad4534f4c5fdebd2a8feb5 /drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | |
parent | 92ed301919932f777713b9172e525674157e983d (diff) | |
download | linux-476af91933ce81d534761d31382459f6e9eb6c6d.tar.xz |
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 'drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c')
0 files changed, 0 insertions, 0 deletions