hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mohammad Kamrul Islam (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HADOOP-10509) cancelToken doesn't work in some instances
Date Wed, 16 Apr 2014 01:08:16 GMT
Mohammad Kamrul Islam created HADOOP-10509:

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


AbstractDelegationTokenSecretManager.cacelToken() gets the owner as full principal name where
as the canceller is the short name.
The potential code snippets:
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");

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
String user = UserGroupInformation.getCurrentUser().getShortUserName();
        jhsDTSecretManager.cancelToken(token, user);
In other cases, the value could be full principal name. REF: FSNamesystem.java.
String canceller = getRemoteUser().getUserName();
      DelegationTokenIdentifier id = dtSecretManager
        .cancelToken(token, canceller);

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

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

View raw message