[
https://issues.apache.org/jira/browse/HADOOP-9461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13625452#comment-13625452
]
Harsh J commented on HADOOP-9461:
---------------------------------
Thanks for taking a look Daryn. Yes the error exactly is:
{code}
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
WARN org.apache.hadoop.security.token.Token: Cannot find class for token kind
MAPREDUCE_DELEGATION_TOKEN
{code}
It is non-fatal, but appears at a high level of log, so is annoying/misleading.
I'll take a look at YARN-320. Do you think this is also worth fixing for
branch-1?
bq. No, services are expected to return null to a token request if security
isn't enabled.
Thanks for clarifying this - I'm guessing they're currently receiving back a
valid token though (at least on my MRv1 tests).
> 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
