[
https://issues.apache.org/jira/browse/HADOOP-13081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15326063#comment-15326063
]
Kai Zheng commented on HADOOP-13081:
------------------------------------
This is a question. Since it's cloning a UGI, it may first clone the subject
exactly, rather than incompletely? Note it's possible to construct a subject
instance with another, looking at it's constructors.
{code}
+
+ /**
+ * @return clone of the UGI with a new subject.
+ */
+ @InterfaceAudience.Public
+ @InterfaceStability.Evolving
+ public UserGroupInformation clone() {
+ Subject subject = new Subject();
+ subject.getPrincipals().addAll(this.getSubject().getPrincipals());
+ // The ctor will set other fields automatically from the principals.
+ return new UserGroupInformation(subject);
+ }
{code}
> 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: Bug
> Reporter: Sergey Shelukhin
> Attachments: 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]
