hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-13805) UGI.getCurrentUser() fails if user does not have a keytab associated
Date Fri, 03 Mar 2017 23:51:45 GMT

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

Daryn Sharp commented on HADOOP-13805:

What exactly broke in EZ because as best I can tell the whole premise of this change and the
"external keytab" concept is completely broken.  I think there's a deeper bug this is attempting
to mask because I've seen the EZ UGI handling - it is completely screwed up and on my to-do
blockers for EZ deployment.

Internally we hacked out the external ugi changes because it broke us.

bq. If you create a UGI from another UGI, ie via getCurrentUser(), the created UGI should
not relogin from keytab, the relogin should be done by the creator UGI if it has a keytab.
bq. My point is, any UGI created from a Subject (directly or via another UGI) should never
attempt to relogin, it is the creator of the responsibility to do so.

Wrong.  Any UGI should be able to relogin a subject regardless of who created it.  Why should
any number of threads be dead in the water waiting for the "owner" to relogin in?  It's a
shared resource.

bq. The bug i'm hitting now is that UGI.getCurrentUser() creates a new UGI and this tries
to do relogin from keytab even if there is no keytab associated to the current UGI. This happens
when HDFS client is accessing encryption zones, specifically the HDFS client interacting with
the KMS client to get encryption keys.

Whoa.  Let's step back for a minute.  The ugi knows if it's from a keytab based on whether
there's a KeyTab instance present.  Why does the ugi think it has a keytab but doesn't have
a keytab?  That makes no sense and is an indicator that the ugi is being grossly misused.

[~alejandro.villa] Please provide more details or a stack trace.

> UGI.getCurrentUser() fails if user does not have a keytab associated
> --------------------------------------------------------------------
>                 Key: HADOOP-13805
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13805
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.8.0, 2.9.0, 3.0.0-alpha2
>            Reporter: Alejandro Abdelnur
>            Assignee: Xiao Chen
>             Fix For: 3.0.0-alpha3
>         Attachments: HADOOP-13805.006.patch, HADOOP-13805.007.patch, HADOOP-13805.008.patch,
HADOOP-13805.009.patch, HADOOP-13805.010.patch, HADOOP-13805.01.patch, HADOOP-13805.02.patch,
HADOOP-13805.03.patch, HADOOP-13805.04.patch, HADOOP-13805.05.patch
> HADOOP-13558 intention was to avoid UGI from trying to renew the TGT when the UGI is
created from an existing Subject as in that case the keytab is not 'own' by UGI but by the
creator of the Subject.
> In HADOOP-13558 we introduced a new private UGI constructor {{UserGroupInformation(Subject
subject, final boolean externalKeyTab)}} and we use with TRUE only when doing a {{UGI.loginUserFromSubject()}}.
> The problem is, when we call {{UGI.getCurrentUser()}}, and UGI was created via a Subject
(via the {{UGI.loginUserFromSubject()}} method), we call {{new UserGroupInformation(subject)}}
which will delegate to {{UserGroupInformation(Subject subject, final boolean externalKeyTab)}}
 and that will use externalKeyTab == *FALSE*. 
> Then the UGI returned by {{UGI.getCurrentUser()}} will attempt to login using a non-existing
keytab if the TGT expired.
> This problem is experienced in {{KMSClientProvider}} when used by the HDFS filesystem
client accessing an an encryption zone.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org

View raw message