Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Fri, 30 Jan 2015 11:27:35 +0000 (UTC)
From: "Harsh J (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12765875.1420754535000.214419.1422617255274@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=3D14298=
513#comment-14298513 ]=20

Harsh J commented on YARN-3021:
-------------------------------

Overall the patch looks fine to me, but please do hold up for [~vinodkv] or=
 another YARN active committer to take a look.

Could you conceive a test case for this as well, to catch regressions in be=
haviour in future? For example it could be done by adding an invalid token =
with the app, but with this option turned on. With the option turned off, s=
uch a thing will always fail and app gets rejected, but with the fix in pro=
per behaviour it will pass through the submit procedure at least. Checkout =
the test-case modified in the earlier patch for a reusable reference.

Also, could you document the added MR config in mapred-default.xml, describ=
ing its use and marking it also as advanced, as it disables some features o=
f a regular resilient application such as token reuse and renewals.

> 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.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)