hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sevada Abraamyan (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2892) Unable to get AMRMToken in unmanaged AM when using a secure cluster
Date Sat, 29 Nov 2014 01:15:12 GMT

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

Sevada Abraamyan commented on YARN-2892:
----------------------------------------

After researching Hadoop security a bit further, I believe the shared cluster scenario I was
thinking about earlier shouldn't be a problem. Administrators define the mapping from principle
to short username via the {{hadoop.security.auth_to_local}} configuration and if two principles
from different kerberos realms mapped to the same user then it would have to be done on purpose
by the administrator. In which case the assumed behavior is that both principles are describing
the same subject and therefore the "users" will have the authorization privileges. Please
correct me if I'm wrong and of course I would love to get a code review of the latest patch.


_In regards to the other mismatches between short/full username in ClientRMService, I will
be opening a different JIRA ticket so as to not dilute the main purpose of this ticket which
was to fix the missing AMRM tokens._

> Unable to get AMRMToken in unmanaged AM when using a secure cluster
> -------------------------------------------------------------------
>
>                 Key: YARN-2892
>                 URL: https://issues.apache.org/jira/browse/YARN-2892
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: resourcemanager
>            Reporter: Sevada Abraamyan
>            Assignee: Sevada Abraamyan
>         Attachments: YARN-2892.patch, YARN-2892.patch
>
>
> An AMRMToken is retrieved from the ApplicationReport by the YarnClient. 
> When the RM creates the ApplicationReport and sends it back to the client it makes a
simple security check whether it should include the AMRMToken in the report (See createAndGetApplicationReport
in RMAppImpl).This security check verifies that the user who submitted the original application
is the same user who is requesting the ApplicationReport. If they are indeed the same user
then it includes the AMRMToken, otherwise it does not include it.
> The problem arises from the fact that when an application is submitted, the RM  saves
the short username of the user who created the application (See submitApplication in ClientRmService).
Afterwards when the ApplicationReport is requested, the system tries to match the full username
of the requester against the previously stored short username. 
> In a secure cluster using Kerberos this check fails because the principle is stripped
from the username when we request a short username. So for example the short username might
be "Foo" whereas the full username is "Foo@Company.com"
> Note: A very similar problem has been previously reported ([Yarn-2232|https://issues.apache.org/jira/browse/YARN-2232])



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message