[
https://issues.apache.org/jira/browse/HDFS-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13887522#comment-13887522
]
Chris Nauroth commented on HDFS-5849:
-
Hi, Arpit. When an access ACL is added to an inode, that ACL must include a
mask entry, either provided by the user or calculated automatically as the
union of the perms on the unnamed group entry, the named user entries, and the
named group entries. Those mask perms get stored into the group permission
bits of the {{FsPermission}}. The mask perms might be different from the
actual group perms, due to the logic described above for mask calculation. The
group perms need to go somewhere else, so they get stored in an unnamed group
ACL entry in the {{AclFeature}}. Later, if the ACL is removed from the inode,
then it would be incorrect to leave the old ACL's mask perms sitting in the
group permission bits of the {{FsPermission}}. Those perms might not be the
same as the group perms. Instead, we need to restore the correct group perms
from the old unnamed group ACL entry back into the {{FsPermission}}.
Now to further complicate things, it's possible that an inode's {{AclFeature}}
contains no access ACL (the ACL used during permission checks) and instead
contains just a default ACL (defines the ACL that newly created files and
sub-directories automatically receive). This case is handled incorrectly in
the current HDFS-4685 codebase, and this patch fixes the bug. When there is no
access ACL, the {{FsPermission}} bits alone define the outcome of permission
checks. The group permission bits already have the expected value, so there is
no need to restore any data back into the {{FsPermission}}.
You might be wondering why we go to all this trouble of storing the mask in the
group permission bits. The reason is that it helps minimize the impact on
existing APIs. For example, the POSIX ACL model states that if someone runs
chmod g-w on a file that has an ACL, then it should have the effect of
removing write permissions for everyone in what they call the group class.
The group class consists of the file's group, all named users in the ACL, and
all named groups in the ACL. By keeping the mask perms in the group permission
bits of {{FsPermission}}, the existing code of {{FSNamesystem#setPermission}}
can just go ahead and write the change into the group permission bits of
{{FsPermission}}. It doesn't realize that it's really changing the mask.
Permission checks use the intersection of the perms in the ACL entries and the
perms in the mask entry to determine the effective permissions. By changing
the mask, {{FSNamesystem#setPermission}} really effectively applies the change
to all users in the group class. Another example of this is ls, which is
supposed to display the mask perms in place of the group perms for inodes that
have an ACL. Instead of changing code in a lot of places like {{getFileInfo}}
and {{globStatus}}, we just let the existing code keep returning the group
permission bits, which is really the mask for files with an ACL.
Hope this helps clarify. Thanks for reviewing, and let me know if you have any
other questions.
Removing ACL from an inode fails if it has only a default ACL.
--
Key: HDFS-5849
URL: https://issues.apache.org/jira/browse/HDFS-5849
Project: Hadoop HDFS
Issue Type: Bug
Components: namenode
Affects Versions: HDFS ACLs (HDFS-4685)
Reporter: Chris Nauroth
Assignee: Chris Nauroth
Attachments: HDFS-5849.1.patch
When removing an ACL, the logic must restore the group permission previously
stored in an ACL entry back into the group permission bits. The logic for
this in {{AclTransformation#removeINodeAcl}} assumes that the group entry
must be found in the former ACL. This is not the case when removing the ACL
from an inode that only had a default ACL and not an access ACL.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
