Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Date: Thu, 9 Jul 2015 22:39:04 +0000 (UTC)
From: "Scott Opell (JIRA)" <jira@apache.org>
To: hdfs-dev@hadoop.apache.org
Message-ID: <JIRA.12843996.1436481487000.148659.1436481544525@Atlassian.JIRA>
In-Reply-To: <JIRA.12843996.1436481487000@Atlassian.JIRA>
References: <JIRA.12843996.1436481487000@Atlassian.JIRA>
 <JIRA.12843996.1436481487117@arcas>
Subject: [jira] [Created] (HDFS-8748) ACL permission check does not union
 groups to determine effective permissions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Scott Opell created HDFS-8748:
---------------------------------

             Summary: ACL permission check does not union groups to determi=
ne 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


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 to=
gether to form effective permissions for the requester.


Instead, the current implementation will search for the first group that gr=
ants 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 fro=
m 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, consid=
er a user
that is a member of 2 groups: sales and execs. The user is not the file own=
er, and the
ACL contains no named user entries. The ACL contains named group entries fo=
r both
groups as follows: group:sales:r=C2=AD=C2=AD, group:execs:=C2=ADw=C2=AD. In=
 this case, the user's effective
permissions are rw=C2=AD.
{quote}

 ??https://issues.apache.org/jira/secure/attachment/12627729/HDFS-ACLs-Desi=
gn-3.pdf page 10??

The design document's algorithm matches that description:

*Design Document Algorithm*
{code:title=3DDesignDocument}
if (user =3D=3D fileOwner) {
    effectivePermissions =3D aclEntries.getOwnerPermissions()
} else if (user =E2=88=88 aclEntries.getNamedUsers()) {
    effectivePermissions =3D aclEntries.getNamedUserPermissions(user)
} else if (userGroupsInAcl !=3D =E2=88=85) {
    effectivePermissions =3D =E2=88=85
    if (fileGroup =E2=88=88 userGroupsInAcl) {
        effectivePermissions =3D effectivePermissions =E2=88=AA
        aclEntries.getGroupPermissions()
    }
    for ({group | group =E2=88=88 userGroupsInAcl}) {
        effectivePermissions =3D effectivePermissions =E2=88=AA
        aclEntries.getNamedGroupPermissions(group)
    }
} else {
    effectivePermissions =3D aclEntries.getOthersPermissions()
}
{code}
??https://issues.apache.org/jira/secure/attachment/12627729/HDFS-ACLs-Desig=
n-3.pdf page 9??

The current implementation does NOT match the description.
*Current Trunk*
{code:title=3DFSPermissionChecker.java}
    // Use owner entry from permission bits if user is owner.
    if (getUser().equals(inode.getUserName())) {
      if (mode.getUserAction().implies(access)) {
        return;
      }
      foundMatch =3D true;
    }

    // Check named user and group entries if user was not denied by owner e=
ntry.
    if (!foundMatch) {
      for (int pos =3D 0, entry; pos < aclFeature.getEntriesSize(); pos++) =
{
        entry =3D aclFeature.getEntryAt(pos);
        if (AclEntryStatusFormat.getScope(entry) =3D=3D AclEntryScope.DEFAU=
LT) {
          break;
        }
        AclEntryType type =3D AclEntryStatusFormat.getType(entry);
        String name =3D AclEntryStatusFormat.getName(entry);
        if (type =3D=3D AclEntryType.USER) {
          // Use named user entry with mask from permission bits applied if=
 user
          // matches name.
          if (getUser().equals(name)) {
            FsAction masked =3D AclEntryStatusFormat.getPermission(entry).a=
nd(
                mode.getGroupAction());
            if (masked.implies(access)) {
              return;
            }
            foundMatch =3D true;
            break;
          }
        } else if (type =3D=3D AclEntryType.GROUP) {
          // Use group entry (unnamed or named) with mask from permission b=
its
          // 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 m=
atch.
          String group =3D name =3D=3D null ? inode.getGroupName() : name;
          if (getGroups().contains(group)) {
            FsAction masked =3D AclEntryStatusFormat.getPermission(entry).a=
nd(
                mode.getGroupAction());
            if (masked.implies(access)) {
              return;
            }
            foundMatch =3D true;
          }
        }
      }
    }
{code}

As seen in the GROUP section, the permissions check will succeed if and onl=
y if a single group (either owning group or named group) has all of the req=
uested permissions. The permissions check should instead succeed if the req=
uested permissions can be obtained by unioning all of the groups permission=
s.


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