hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Nauroth (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5849) Removing ACL from an inode fails if it has only a default ACL.
Date Fri, 31 Jan 2014 06:42:09 GMT

    [ 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)

Mime
View raw message