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-8748) ACL permission check does not union groups to determine effective permissions
Date Mon, 20 Jul 2015 23:46:06 GMT

    [ https://issues.apache.org/jira/browse/HDFS-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14634288#comment-14634288
] 

Chris Nauroth commented on HDFS-8748:
-------------------------------------

Thank you for the pointer to 1003.1e.  That's a very interesting find.  The high-level goal
always has been POSIX adherence, which makes me inclined to leave the current code as is.

> ACL permission check does not union groups to determine effective permissions
> -----------------------------------------------------------------------------
>
>                 Key: HDFS-8748
>                 URL: https://issues.apache.org/jira/browse/HDFS-8748
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: HDFS
>    Affects Versions: 2.7.1
>            Reporter: Scott Opell
>              Labels: acl, permission
>         Attachments: HDFS_8748.patch
>
>
> In the ACL permission checking routine, the implemented named group section does not
match the design document.
> In the design document, its shown in the pseudo-code that if the requester is not the
owner or a named user, then the applicable groups are unioned together to form effective permissions
for the requester.
> Instead, the current implementation will search for the first group that grants access
and will use that. It will not union the permissions together.
> Here is the design document's description of the desired behavior
> {quote}
> If the user is a member of the file's group or at least one group for which there is
a
> named group entry in the ACL, then effective permissions are calculated from groups.
> This is the union of the file group permissions (if the user is a member of the file
group)
> and all named group entries matching the user's groups. For example, consider a user
> that is a member of 2 groups: sales and execs. The user is not the file owner, and the
> ACL contains no named user entries. The ACL contains named group entries for both
> groups as follows: group:sales:r­­\-\-, group:execs:\-­w\-­. In this case, the user's
effective
> permissions are rw­-.
> {quote}
>  ??https://issues.apache.org/jira/secure/attachment/12627729/HDFS-ACLs-Design-3.pdf page
10??
> The design document's algorithm matches that description:
> *Design Document Algorithm*
> {code:title=DesignDocument}
> if (user == fileOwner) {
>     effectivePermissions = aclEntries.getOwnerPermissions()
> } else if (user ∈ aclEntries.getNamedUsers()) {
>     effectivePermissions = aclEntries.getNamedUserPermissions(user)
> } else if (userGroupsInAcl != ∅) {
>     effectivePermissions = ∅
>     if (fileGroup ∈ userGroupsInAcl) {
>         effectivePermissions = effectivePermissions ∪
>         aclEntries.getGroupPermissions()
>     }
>     for ({group | group ∈ userGroupsInAcl}) {
>         effectivePermissions = effectivePermissions ∪
>         aclEntries.getNamedGroupPermissions(group)
>     }
> } else {
>     effectivePermissions = aclEntries.getOthersPermissions()
> }
> {code}
> ??https://issues.apache.org/jira/secure/attachment/12627729/HDFS-ACLs-Design-3.pdf page
9??
> The current implementation does NOT match the description.
> *Current Trunk*
> {code:title=FSPermissionChecker.java}
>     // Use owner entry from permission bits if user is owner.
>     if (getUser().equals(inode.getUserName())) {
>       if (mode.getUserAction().implies(access)) {
>         return;
>       }
>       foundMatch = true;
>     }
>     // Check named user and group entries if user was not denied by owner entry.
>     if (!foundMatch) {
>       for (int pos = 0, entry; pos < aclFeature.getEntriesSize(); pos++) {
>         entry = aclFeature.getEntryAt(pos);
>         if (AclEntryStatusFormat.getScope(entry) == AclEntryScope.DEFAULT) {
>           break;
>         }
>         AclEntryType type = AclEntryStatusFormat.getType(entry);
>         String name = AclEntryStatusFormat.getName(entry);
>         if (type == AclEntryType.USER) {
>           // Use named user entry with mask from permission bits applied if user
>           // matches name.
>           if (getUser().equals(name)) {
>             FsAction masked = AclEntryStatusFormat.getPermission(entry).and(
>                 mode.getGroupAction());
>             if (masked.implies(access)) {
>               return;
>             }
>             foundMatch = true;
>             break;
>           }
>         } else if (type == AclEntryType.GROUP) {
>           // Use group entry (unnamed or named) with mask from permission bits
>           // applied if user is a member and entry grants access.  If user is a
>           // member of multiple groups that have entries that grant access, then
>           // it doesn't matter which is chosen, so exit early after first match.
>           String group = name == null ? inode.getGroupName() : name;
>           if (getGroups().contains(group)) {
>             FsAction masked = AclEntryStatusFormat.getPermission(entry).and(
>                 mode.getGroupAction());
>             if (masked.implies(access)) {
>               return;
>             }
>             foundMatch = true;
>           }
>         }
>       }
>     }
> {code}
> As seen in the GROUP section, the permissions check will succeed if and only if a single
group (either owning group or named group) has all of the requested permissions. The permissions
check should instead succeed if the requested permissions can be obtained by unioning all
of the groups permissions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message