[
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
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
