[
https://issues.apache.org/jira/browse/HADOOP-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549646#comment-15549646
]
Sergey Shelukhin commented on HADOOP-13066:
-------------------------------------------
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 gathers the tokens and passes them on; 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, they want 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 of our service, 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: [email protected]
For additional commands, e-mail: [email protected]
