hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3103) AMRMClientImpl does not update AMRM token properly
Date Tue, 27 Jan 2015 19:26:36 GMT

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

Jason Lowe commented on YARN-3103:

Sorry for the confusion, I'll try to go through it step-by-step.  It's similar to the problem
we saw in MAPREDUCE-6230 which is the same kind of AMRM token updating code, just in the MR-AM
code rather than the AMRMClientImpl code.

# The RM creates an AMRM token as part of setting up the AM's launch context.  That token
is created with an empty service name, see AMRMSecretManager.createAndGetAMRMToken.
# The RM then pokes this token into the launch context credentials, using the token's service
name as the key.  See AMLauncher.setupTokens and Credentials.addToken.  We now have an AMRM
token in the credentials mapped under an empty service name as the key.
# When the AMRMClient receives an updated AMRM token it updates the service name of the token
_before_ it pokes it into the credentials.  See AMRMClientImpl.updateAMRMToken.  Therefore
we are adding the token using a non-empty service name as the key in the credentials token
# After updating the credentials we now have _two_ AMRM tokens in the credentials map, one
with an empty service name key (but a non-empty service name on the token itself) and one
where the service name key equals the token's service name.  In other words, we failed to
replace the existing AMRM token in the credentials

Also for a secure setup, we're updating the wrong UGI.  IIUC the ClientRMProxy will use the
UGI obtained from the current user when performing the connection to the RM, so updating the
login user rather than the current user can update the wrong UGI if we're currently running
in a doAs context where the UGI isn't the login UGI.

> AMRMClientImpl does not update AMRM token properly
> --------------------------------------------------
>                 Key: YARN-3103
>                 URL: https://issues.apache.org/jira/browse/YARN-3103
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 2.6.0
>            Reporter: Jason Lowe
>            Assignee: Jason Lowe
>            Priority: Blocker
> AMRMClientImpl.updateAMRMToken updates the token service _before_ storing it to the credentials,
so the token is mapped using the newly updated service rather than the empty service that
was used when the RM created the original AMRM token.  This leads to two AMRM tokens in the
credentials and can still fail if the AMRMTokenSelector picks the wrong one.
> In addition the AMRMClientImpl grabs the login user rather than the current user when
security is enabled, so it's likely the UGI being updated is not the UGI that will be used
when reconnecting to the RM.
> The end result is that AMs can fail with invalid token errors when trying to reconnect
to an RM after a new AMRM secret has been activated.

This message was sent by Atlassian JIRA

View raw message