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

Hudson commented on YARN-2936:
------------------------------

SUCCESS: Integrated in Hadoop-Hdfs-trunk-Java8 #64 (See 
[https://builds.apache.org/job/Hadoop-Hdfs-trunk-Java8/64/])
YARN-2936. Changed YARNDelegationTokenIdentifier to set proto fields on 
getProto method. Contributed by Varun Saxena (jianhe: rev 
2638f4d0f0da375b0dd08f3188057637ed0f32d5)
* hadoop-yarn-project/CHANGES.txt
* 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common/src/test/java/org/apache/hadoop/yarn/security/TestYARNTokenIdentifier.java
* 
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common/src/main/java/org/apache/hadoop/yarn/security/client/YARNDelegationTokenIdentifier.java


> YARNDelegationTokenIdentifier doesn't set proto.builder now
> -----------------------------------------------------------
>
>                 Key: YARN-2936
>                 URL: https://issues.apache.org/jira/browse/YARN-2936
>             Project: Hadoop YARN
>          Issue Type: Bug
>            Reporter: Zhijie Shen
>            Assignee: Varun Saxena
>             Fix For: 2.7.0
>
>         Attachments: YARN-2936.001.patch, YARN-2936.002.patch, 
> YARN-2936.003.patch, YARN-2936.004.patch, YARN-2936.005.patch, 
> YARN-2936.006.patch
>
>
> After YARN-2743, the setters are removed from YARNDelegationTokenIdentifier, 
> such that when constructing a object which extends 
> YARNDelegationTokenIdentifier, proto.builder is not set at all. Later on, 
> when we call getProto() of it, we will just get an empty proto object.
> It seems to do no harm to the production code path, as we will always call 
> getBytes() before using proto to persist the DT in the state store, when we 
> generating the password.
> I think the setter is removed to avoid duplicating setting the fields why 
> getBytes() is called. However, YARNDelegationTokenIdentifier doesn't work 
> properly alone. YARNDelegationTokenIdentifier is tightly coupled with the 
> logic in secretManager. It's vulnerable if something is changed at 
> secretManager. For example, in the test case of YARN-2837, I spent time to 
> figure out we need to execute getBytes() first to make sure the testing DTs 
> can be properly put into the state store.



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

Reply via email to