[
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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
