hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wei-Chiu Chuang (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HADOOP-12468) Partial group resolution failure should not result in user lockout
Date Thu, 08 Oct 2015 23:07:26 GMT
Wei-Chiu Chuang created HADOOP-12468:
----------------------------------------

             Summary: Partial group resolution failure should not result in user lockout
                 Key: HADOOP-12468
                 URL: https://issues.apache.org/jira/browse/HADOOP-12468
             Project: Hadoop Common
          Issue Type: Bug
          Components: security
         Environment: Linux
            Reporter: Wei-Chiu Chuang
            Assignee: Wei-Chiu Chuang
            Priority: Minor


If a Hadoop cluster is configured to use ShellBasedUnixGroupsMapping for user/group name mapping,
occasionally some group names may become unresolvable (for example, using SSSD). 

ShellBasedUnixGroupsMapping uses shell command "id -Gn" to retrieve the group name of a user;
however, the existing logic assumes that if the exit code of the command is non-zero, the
user has no group name at all. The shell command in Linux returns non-zero exit code if a
group name is not resolvable. Unfortunately, it is possible that a user belongs to multiple
groups, and any partial failure in group name resolution would denied the user's access.

On the other hand, the JNI implementation (JniBasedUnixGroupsMapping) is more resilient. If
any group name is unresolvable, it is simply ignored, and whatever are resolvable are returned.

It is arguable that if the group name is not resolvable, the administrator should configure
their directory/authentication service correctly, and Hadoop is in no position to handle it,
but since the existing unit tests assume the output of JNI-based and shell-based implementation
are the same, we should improve the shell-based group name resolution, and make it as resilient
as the JNI-based one.



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

Mime
View raw message