[jira] [Updated] (MAPREDUCE-5884) History server uses short user name when canceling tokens
[
https://issues.apache.org/jira/browse/MAPREDUCE-5884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Lowe updated MAPREDUCE-5884:
--
Summary: History server uses short user name when canceling tokens (was:
cancelToken doesn't work in some instances)
Moved to MAPREDUCE and updated the title accordingly for commit.
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)
[jira] [Updated] (MAPREDUCE-5884) History server uses short user name when canceling tokens
[
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)
