[
https://issues.apache.org/jira/browse/HADOOP-13251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15348568#comment-15348568
]
Andrew Wang commented on HADOOP-13251:
--------------------------------------
Do you feel that conditionally unsetting the DT is hacky? That we don't have
easy access to the op in authenticate makes me think it should be in the
implementation-specific doDelegationTokenOperation.
Personally, I find manual query string parsing to be hacky. URL query strings
can have a key with no value as well as duplicate keys, which is why I wanted
to use a library.
> DelegationTokenAuthenticationHandler should detect actual renewer when renew
> token
> ----------------------------------------------------------------------------------
>
> Key: HADOOP-13251
> URL: https://issues.apache.org/jira/browse/HADOOP-13251
> Project: Hadoop Common
> Issue Type: Bug
> Components: kms
> Affects Versions: 2.8.0
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Attachments: HADOOP-13251.01.patch, HADOOP-13251.02.patch,
> HADOOP-13251.03.patch, HADOOP-13251.04.patch, HADOOP-13251.05.patch,
> HADOOP-13251.06.patch, HADOOP-13251.07.patch, HADOOP-13251.08.patch,
> HADOOP-13251.08.patch, HADOOP-13251.innocent.patch
>
>
> Turns out KMS delegation token renewal feature (HADOOP-13155) does not work
> well with client side impersonation.
> In a MR example, an end user (UGI:user) gets all kinds of DTs (with
> renewer=yarn), and pass them to Yarn. Yarn's resource manager (UGI:yarn) then
> renews these DTs as long as the MR jobs are running. But currently, the token
> is used at the kms server side to decide the renewer, in which case is always
> the token's owner. This ends up rejecting the renew request due to renewer
> mismatch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
