[
https://issues.apache.org/jira/browse/HADOOP-10509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13971439#comment-13971439
]
Daryn Sharp commented on HADOOP-10509:
--------------------------------------
I tried to fix this general inconsistency in past. The full principal should
be used for validating token operations. If one specifies a specific principal
(ex. user/host@REALM), it shouldn't be expected behavior for "user" from
anywhere to have privileges to the token. The JHS should be fixed.
> 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
> Reporter: Mohammad Kamrul Islam
> Assignee: Mohammad Kamrul Islam
>
> 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)
