[
https://issues.apache.org/jira/browse/HADOOP-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13973779#comment-13973779
]
Hadoop QA commented on HADOOP-10509:
------------------------------------
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12640764/HADOOP-10509.1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 2 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. There were no new javadoc warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-HADOOP-Build/3808//testReport/
Console output:
https://builds.apache.org/job/PreCommit-HADOOP-Build/3808//console
This message is automatically generated.
> cancelToken doesn't work in some instances
> ------------------------------------------
>
> Key: HADOOP-10509
> URL: https://issues.apache.org/jira/browse/HADOOP-10509
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.3.0
> Reporter: Mohammad Kamrul Islam
> Assignee: Mohammad Kamrul Islam
> Fix For: 2.5.0
>
> Attachments: HADOOP-10509.1.patch
>
>
> When the owner of a token tries to explicitly cancel the token, it gets the
> following error/exception
> {noformat}
> 2014-04-14 20:07:35,744 WARN org.apache.hadoop.security.UserGroupInformation:
> PriviledgedActionException
> as:<someuser>/<machine_name>.linkedin.com@<realm>.LINKEDIN.COM
> (auth:KERBEROS) cause:org.apache.hadoop.security.AccessControlException:
> <someuser> is not authorized to cancel the token
> 2014-04-14 20:07:35,744 INFO org.apache.hadoop.ipc.Server: IPC Server handler
> 2 on 10020, call
> org.apache.hadoop.mapreduce.v2.api.HSClientProtocolPB.cancelDelegationToken
> from 172.20.158.61:49042 Call#4 Retry#0: error:
> org.apache.hadoop.security.AccessControlException: <someuser> is not
> authorized to cancel the token
> org.apache.hadoop.security.AccessControlException: <someuser> is not
> authorized to cancel the token
> at
> org.apache.hadoop.security.token.delegation.AbstractDelegationTokenSecretManager.cancelToken(AbstractDelegationTokenSecretManager.java:429)
> at
> org.apache.hadoop.mapreduce.v2.hs.HistoryClientService$HSClientProtocolHandler.cancelDelegationToken(HistoryClientService.java:400)
> at
> org.apache.hadoop.mapreduce.v2.api.impl.pb.service.MRClientProtocolPBServiceImpl.cancelDelegationToken(MRClientProtocolPBServiceImpl.java:286)
> at
> org.apache.hadoop.yarn.proto.MRClientProtocol$MRClientProtocolService$2.callBlockingMethod(MRClientProtocol.java:301)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:585)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:928)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1962)
> at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1958)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1548)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1956)
> {noformat}
> Details:
> AbstractDelegationTokenSecretManager.cacelToken() gets the owner as full
> principal name where as the canceller is the short name.
> The potential code snippets:
> {code}
> String owner = id.getUser().getUserName();
> Text renewer = id.getRenewer();
> HadoopKerberosName cancelerKrbName = new HadoopKerberosName(canceller);
> String cancelerShortName = cancelerKrbName.getShortName();
> if (!canceller.equals(owner)
> && (renewer == null || renewer.toString().isEmpty() ||
> !cancelerShortName
> .equals(renewer.toString()))) {
> throw new AccessControlException(canceller
> + " is not authorized to cancel the token");
> }
> {code}
> The code shows 'owner' gets the full principal name. Where as the value of
> 'canceller' depends on who is calling it.
> In some cases, it is the short name. REF: HistoryClientService.java
> {code}
> String user = UserGroupInformation.getCurrentUser().getShortUserName();
> jhsDTSecretManager.cancelToken(token, user);
> {code}
>
> In other cases, the value could be full principal name. REF:
> FSNamesystem.java.
> {code}
> String canceller = getRemoteUser().getUserName();
> DelegationTokenIdentifier id = dtSecretManager
> .cancelToken(token, canceller);
> {code}
> Possible resolution:
> --------------------------
> Option 1: in cancelToken() method, compare with both : short name and full
> principal name.
> Pros: Easy. Have to change in one place.
> Cons: Someone can argue that it is hacky!
>
> Option 2:
> All the caller sends the consistent value as 'canceller' : either short name
> or full principal name.
> Pros: Cleaner.
> Cons: A lot of code changes and potential bug injections.
> I'm open for both options.
> Please give your opinion.
> Btw, how it is working now in most cases? The short name and the full
> principal name are usually the same for end-users.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
