[jira] [Commented] (HADOOP-9461) JobTracker and NameNode both grant delegation tokens to non-secure clients

["Daryn Sharp (JIRA)" <ji...@apache.org>]

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

Daryn Sharp commented on HADOOP-9461:
-------------------------------------

bq. 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.
What is the error message?  Is it about the renewer being incorrect?  If so, this was resolved in trunk/2/23 via YARN-320.

bq. Ideally such clients ought to get an error if they request a DT in non-secure mode.
No, services are expected to return null to a token request if security isn't enabled.  The client is supposed to interpret this as no token is required.  This pattern is supposed to allow a client to operate against both a secure and insecure cluster.
                
> 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