[ https://issues.apache.org/jira/browse/HDFS-5849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)