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

Yongjun Zhang commented on YARN-3021:
-------------------------------------

Hi [~vinodkv],

Thanks for your further look and confirm that the uploaded patch would work.

About your non-code comments, I assume you meant to " inspect the incoming 
renewer specified in the token and skip renewing those tokens if the renewer 
doesn't match it's own address". I have two thoughts:

* Seems regardless of this jira, we could do a renewer address match as a 
validation step. Right?
* In this case, actually looks like the renewer would be cluster A's yarn, 
based on {{TokenCache@obtainTokensForNamenodesInternal}} and 
{{Master.getMasterPrincipal}}. 

{code}
public static String getMasterUserName(Configuration conf) {
    String framework = conf.get(MRConfig.FRAMEWORK_NAME, 
MRConfig.YARN_FRAMEWORK_NAME);
    if (framework.equals(MRConfig.CLASSIC_FRAMEWORK_NAME)) {    
      return conf.get(MRConfig.MASTER_USER_NAME);
    } 
    else {
      return conf.get(YarnConfiguration.RM_PRINCIPAL);
    }
  }
{code}

So it looks like that even if we check, the renewer would match in this case. 
Please correct me if I'm wrong.

Thanks.





> YARN's delegation-token handling disallows certain trust setups to operate 
> 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 COMMON, 
> and B trusts COMMON (one way trusts both), and both A and B run HDFS + YARN 
> clusters.
> Now if one logs in with a COMMON credential, and runs a job on A's YARN that 
> needs to access B's HDFS (such as a DistCp), the operation fails in the RM, 
> as it attempts a renewDelegationToken(…) 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 asynchronously 
> and once the renewal attempt failed we simply ceased to schedule any further 
> attempts of renewals, rather than fail the job immediately.
> We should change the logic such that we attempt the renewal but go easy on 
> the failure and skip the scheduling alone, rather than bubble back an error 
> 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)

Reply via email to