[
https://issues.apache.org/jira/browse/HADOOP-13081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15544287#comment-15544287
]
Chris Nauroth commented on HADOOP-13081:
----------------------------------------
This JIRA will take one of two directions depending on discussion:
* If this becomes effectively a "Won't Fix", then re-resolve this as fixed in
3.0.0-alpha1 and open a new JIRA to track removal of the API in 3.0.0-alpha2,
for the sake of accuracy in release notes.
* If the change is accepted in some form, then re-resolve this as fixed in
3.0.0-alpha1 and open a new JIRA targeted to 3.0.0-alpha2 and 2.8.0 to track
the corrected patch.
[~sershe], I think you're best equipped to provide justification for this API,
because you're effectively already doing it via reflection in Hive.
bq. We don't have control over which parts of the code need kerberos or tokens;
I suspect that usually only one would be needed but we don't know which one.
Can you describe why you don't have control? Intuitively, I'd expect to see
isolated pieces of code that need to make service calls on behalf of the user
with delegation token (a separate UGI), and then other parts of the code acting
as the privileged user. Maybe I'm not understanding the full context.
> add the ability to create multiple UGIs/subjects from one kerberos login
> ------------------------------------------------------------------------
>
> Key: HADOOP-13081
> URL: https://issues.apache.org/jira/browse/HADOOP-13081
> Project: Hadoop Common
> Issue Type: Improvement
> Components: security
> Reporter: Sergey Shelukhin
> Assignee: Sergey Shelukhin
> Fix For: 2.8.0, 3.0.0-alpha1
>
> Attachments: HADOOP-13081.01.patch, HADOOP-13081.02.patch,
> HADOOP-13081.02.patch, HADOOP-13081.03.patch, HADOOP-13081.03.patch,
> HADOOP-13081.patch
>
>
> We have a scenario where we log in with kerberos as a certain user for some
> tasks, but also want to add tokens to the resulting UGI that would be
> specific to each task. We don't want to authenticate with kerberos for every
> task.
> I am not sure how this can be accomplished with the existing UGI interface.
> Perhaps some clone method would be helpful, similar to createProxyUser minus
> the proxy stuff; or it could just relogin anew from ticket cache.
> getUGIFromTicketCache seems like the best option in existing code, but there
> doesn't appear to be a consistent way of handling ticket cache location - the
> above method, that I only see called in test, is using a config setting that
> is not used anywhere else, and the env variable for the location that is used
> in the main ticket cache related methods is not set uniformly on all paths -
> therefore, trying to find the correct ticket cache and passing it via the
> config setting to getUGIFromTicketCache seems even hackier than doing the
> clone via reflection ;) Moreover, getUGIFromTicketCache ignores the user
> parameter on the main path - it logs a warning for multiple principals and
> then logs in with first available.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
