[ https://issues.apache.org/jira/browse/MAPREDUCE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Lowe updated MAPREDUCE-5884: ---------------------------------- Resolution: Fixed Fix Version/s: 3.0.0 Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks, Mohammad! I committed this to trunk and branch-2. > History server uses short user name when canceling tokens > --------------------------------------------------------- > > Key: MAPREDUCE-5884 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5884 > Project: Hadoop Map/Reduce > Issue Type: Bug > Components: jobhistoryserver, security > Affects Versions: 2.3.0 > Reporter: Mohammad Kamrul Islam > Assignee: Mohammad Kamrul Islam > Fix For: 3.0.0, 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)