[
https://issues.apache.org/jira/browse/HADOOP-9461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625705#comment-13625705
]
Daryn Sharp commented on HADOOP-9461:
-------------------------------------
bq. ERROR org.apache.hadoop.security.UserGroupInformation:
PriviledgedActionException as:mapred (auth:SIMPLE)
cause:org.apache.hadoop.security.AccessControlException: Client mapred tries to
renew a token with renewer specified as mr token
This is the issue I expected to see - which is resolved by YARN-320. It's only
an issue if security is enabled and a job needs to submit a sub-job more than
1d later. Even though an insecure JT is issuing tokens, an insecure client
won't send the token, and even if it does, the insecure JT tells the client to
switch back to SIMPLE.
If you want to backport YARN-320, it shouldn't be too hard. The suboptimal
workaround for secure clusters is to increase the MR token's expiration to
something like 1w so renewal isn't necessary.
bq. WARN org.apache.hadoop.security.token.Token: Cannot find class for token
kind MAPREDUCE_DELEGATION_TOKEN
This is odd because it found the class to get the mismatched renewer error.
Maybe I'm misremembering the token types in 1.x.
> JobTracker and NameNode both grant delegation tokens to non-secure clients
> --------------------------------------------------------------------------
>
> Key: HADOOP-9461
> URL: https://issues.apache.org/jira/browse/HADOOP-9461
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Harsh J
> Assignee: Harsh J
> Priority: Minor
>
> If one looks at the MAPREDUCE-1516 added logic in JobTracker.java's
> isAllowedDelegationTokenOp() method, and apply non-secure states of
> UGI.isSecurityEnabled == false and authMethod == SIMPLE, the return result is
> true when the intention is false (due to the shorted conditionals).
> This is allowing non-secure JobClients to easily request and use
> DelegationTokens and cause unwanted errors to be printed in the JobTracker
> when the renewer attempts to run. Ideally such clients ought to get an error
> if they request a DT in non-secure mode.
> HDFS in trunk and branch-1 both too have the same problem. Trunk MR
> (HistoryServer) and YARN are however, unaffected due to a simpler, inlined
> logic instead of reuse of this faulty method.
> Note that fixing this will break Oozie today, due to the merged logic of
> OOZIE-734. Oozie will require a fix as well if this is to be fixed in
> branch-1. As a result, I'm going to mark this as an Incompatible Change.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
