Return-Path: X-Original-To: apmail-hadoop-yarn-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-yarn-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2BF7810D84 for ; Tue, 3 Mar 2015 21:23:20 +0000 (UTC) Received: (qmail 71670 invoked by uid 500); 3 Mar 2015 21:23:05 -0000 Delivered-To: apmail-hadoop-yarn-issues-archive@hadoop.apache.org Received: (qmail 71630 invoked by uid 500); 3 Mar 2015 21:23:05 -0000 Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: yarn-issues@hadoop.apache.org Delivered-To: mailing list yarn-issues@hadoop.apache.org Received: (qmail 71619 invoked by uid 99); 3 Mar 2015 21:23:05 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Mar 2015 21:23:05 +0000 Date: Tue, 3 Mar 2015 21:23:05 +0000 (UTC) From: "Jian He (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (YARN-3021) YARN's delegation-token handling disallows certain trust setups to operate properly over DistCp MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/YARN-3021?page=3Dcom.atlassian.= jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D14345= 755#comment-14345755 ]=20 Jian He commented on YARN-3021: ------------------------------- bq. Overall I think "automatic token renewal" has always been an "auxiliary= service" provided by YARN's RM. I think this raised a point that the DelegationTokenRenewal is just an auxi= liary service, not a fundamental service required by YARN. RM today happens= to be the renewer, in the long term solution, we can point the renewer to= a real centralized renewal service to support such cross-platform trust se= tup. Instead of explicitly adding a user-facing API and deprecate the API = in the future, we may choose to add a server-side config to not let applica= tion fail if renewal fails. thoughts ? > YARN's delegation-token handling disallows certain trust setups to operat= e properly over DistCp > -------------------------------------------------------------------------= ---------------------- > > 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.= 003.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)