hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yongjun Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7146) NFS ID/Group lookup requires SSSD enumeration on the server
Date Wed, 08 Oct 2014 21:26:34 GMT

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

Yongjun Zhang commented on HDFS-7146:

Hi [~aw], 

Thanks for your input. I did some search per your comment, I guess you were referring to Groups.java
and JniBasedUnixGroupsMappingWithFallback related code in hadoop-common area? 

Given that these two areas are doing similar things, I agree with you that we will try our
best to consolidate. Since there are already two caching mechanisms in the current code base
(nfs, hadoop-common), do you think it's reasonable to limit the scope of this jira to fix
the particular issue that we are trying to fix in nfs mechanism, and open a new jira for unifying
the implementation?

 I looked at the hadoop-common area, its content appears to be quite different than what's
need by the current the nfs code (IdUserGroup.java), so I expect the scope of change to consolidate
them would be much larger. What do you think?

Thanks a lot. 

> NFS ID/Group lookup requires SSSD enumeration on the server
> -----------------------------------------------------------
>                 Key: HDFS-7146
>                 URL: https://issues.apache.org/jira/browse/HDFS-7146
>             Project: Hadoop HDFS
>          Issue Type: Bug
>          Components: nfs
>    Affects Versions: 2.6.0
>            Reporter: Yongjun Zhang
>            Assignee: Yongjun Zhang
>         Attachments: HDFS-7146.001.patch, HDFS-7146.002.allIncremental.patch, HDFS-7146.003.patch
> The current implementation of the NFS UID and GID lookup works by running 'getent passwd'
with an assumption that it will return the entire list of users available on the OS, local
and remote (AD/etc.).
> This behaviour of the command is advised to be and is prevented by administrators in
most secure setups to avoid excessive load to the ADs involved, as the # of users to be listed
may be too large, and the repeated requests of ALL users not present in the cache would be
too much for the AD infrastructure to bear.
> The NFS server should likely do lookups based on a specific UID request, via 'getent
passwd <UID>', if the UID does not match a cached value. This reduces load on the LDAP
backed infrastructure.
> Thanks [~qwertymaniac] for reporting the issue.

This message was sent by Atlassian JIRA

View raw message