You are viewing a plain text version of this content. The canonical link for it is here.
Posted to common-issues@hadoop.apache.org by "Sergey Shelukhin (JIRA)" <ji...@apache.org> on 2016/10/10 19:25:20 UTC

[jira] [Issue Comment Deleted] (HADOOP-13066) UserGroupInformation.loginWithKerberos/getLoginUser is not thread-safe

     [ https://issues.apache.org/jira/browse/HADOOP-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Shelukhin updated HADOOP-13066:
--------------------------------------
    Comment: was deleted

(was: The scenario is like this; we accept work on behalf of clients that is, generally speaking, authorized on a higher level (those are fragments of Hive jobs right now, except unlike MR they all run in-process, and we are also making the external client which is the crux of the matter). In normal case, the service doing the auth (HiveServer2 in case of Hive) gathers the tokens and passes them on to the service running the fragment; the external client may supply some tokens too. However, apparently for some clients it's difficult (or not implemented yet) to gather tokens, so in the cases of perimeter security, we want to be able to configure access in such way that they can access all of HDFS (for example; it could be some other service that their code touched that we have no idea about, hypothetically). The reasoning is that if the work item has passed thru the authorization that our service does, they don't care about HDFS security any more. In that case, our service would log in from keytab and run their item in that context. However, we neither want to require a super-user that is able to access all possible services (e.g. HBase), nor disable HDFS security altogether. So, the user work items would access HDFS (or HBase or whatever) as a user with lots of access, by design, and access other services via tokens.
This feature is off by default, obviously, and the of their code talking to services is based entirely on tokens by default.
I understand running as such user is not an ideal situation but it is apparently a valid scenario for some cases.
So, what we do now is create a master UGI/Subject; for every task, if this is enabled, we clone that via reflection and add the tokens. We haven't extensively tested this yet since external client is not production ready but it appears to work in some tests.

I hope this makes sense, feel free to clarify.
We are using reflection to get the subject and construct the UGI from subject.)

> UserGroupInformation.loginWithKerberos/getLoginUser is not thread-safe
> ----------------------------------------------------------------------
>
>                 Key: HADOOP-13066
>                 URL: https://issues.apache.org/jira/browse/HADOOP-13066
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: security
>            Reporter: Sergey Shelukhin
>
> When calling loginFromKerberos, a static variable is set up with the result. If someone logs in as a different user from a different thread, the call to getLoginUser will not return the correct UGI.



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

---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: common-issues-help@hadoop.apache.org