Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Mon, 2 Feb 2015 21:26:36 +0000 (UTC)
From: "zhihai xu (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12765875.1420754535000.233291.1422912396053@Atlassian.JIRA>
In-Reply-To: <JIRA.12765875.1420754535000@Atlassian.JIRA>
References: <JIRA.12765875.1420754535000@Atlassian.JIRA>
 <JIRA.12765875.1420754535030@arcas>
Subject: [jira] [Commented] (YARN-3021) YARN's delegation-token handling
 disallows certain trust setups to operate properly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/YARN-3021?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D14301=
964#comment-14301964 ]=20

zhihai xu commented on YARN-3021:
---------------------------------

bq. There is another place in RMAppImpl#transition that calls DeletationTok=
enRenewer#addApplicationSync
IMO, we should do the same change in RMAppImpl#RMAppRecoveredTransition to =
skip renewing the Token during recovery.

> YARN's delegation-token handling disallows certain trust setups to operat=
e properly
> -------------------------------------------------------------------------=
----------
>
>                 Key: YARN-3021
>                 URL: https://issues.apache.org/jira/browse/YARN-3021
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: security
>    Affects Versions: 2.3.0
>            Reporter: Harsh J
>         Attachments: YARN-3021.001.patch, YARN-3021.002.patch, YARN-3021.=
patch
>
>
> Consider this scenario of 3 realms: A, B and COMMON, where A trusts COMMO=
N, and B trusts COMMON (one way trusts both), and both A and B run HDFS + Y=
ARN clusters.
> Now if one logs in with a COMMON credential, and runs a job on A's YARN t=
hat needs to access B's HDFS (such as a DistCp), the operation fails in the=
 RM, as it attempts a renewDelegationToken(=E2=80=A6) synchronously during =
application submission (to validate the managed token before it adds it to =
a scheduler for automatic renewal). The call obviously fails cause B realm =
will not trust A's credentials (here, the RM's principal is the renewer).
> In the 1.x JobTracker the same call is present, but it is done asynchrono=
usly and once the renewal attempt failed we simply ceased to schedule any f=
urther attempts of renewals, rather than fail the job immediately.
> We should change the logic such that we attempt the renewal but go easy o=
n the failure and skip the scheduling alone, rather than bubble back an err=
or to the client, failing the app submission. This way the old behaviour is=
 retained.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)