hadoop-mapreduce-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MAPREDUCE-5884) History server uses short user name when canceling tokens
Date Sun, 11 May 2014 01:35:19 GMT

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

Hudson commented on MAPREDUCE-5884:
-----------------------------------

FAILURE: Integrated in Hadoop-Mapreduce-trunk #1778 (See [https://builds.apache.org/job/Hadoop-Mapreduce-trunk/1778/])
MAPREDUCE-5884. History server uses short user name when canceling tokens. Contributed by
Mohammad Kamrul Islam (jlowe: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1593422)
* /hadoop/common/trunk/hadoop-mapreduce-project/CHANGES.txt
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/main/java/org/apache/hadoop/mapreduce/v2/hs/HistoryClientService.java
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-hs/src/test/java/org/apache/hadoop/mapreduce/v2/hs/TestJHSDelegationTokenSecretManager.java
* /hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/test/java/org/apache/hadoop/mapreduce/security/TestJHSSecurity.java


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

Mime
View raw message