[jira] [Commented] (HADOOP-10509) cancelToken doesn't work in some instances

["Mohammad Kamrul Islam (JIRA)" <ji...@apache.org>]

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

Mohammad Kamrul Islam commented on HADOOP-10509:
------------------------------------------------

Can someone please review or commit this patch?

> 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)