Chris Nauroth commented on HADOOP-13081:

[~daryn], great review.  Thank you.

To summarize (at least from my own understanding), we need to revert the 
current patch and post a new revision that at least adds this:

* Address thread safety.  Is it sufficient to make the whole method body 
{{synchronized (subject)}}, similar to {{addCredentials}}, {{getCredentials}}, 
* Clone into an insertion order preserving {{Set}} implementation 

bq. Relogin of a clone ugi will wipe out the kerberos credentials in the 
original ugi. The hadoop User principal contains the login context which 
references the original subject.

I had thought this part was OK, resulting in successful relogin for both 
original and cloned UGI.  Was I wrong?  ("wipe out" sounds bad.)  If this part 
is not OK, then is the proposed change to replace the {{User}} principal in the 
clone with a new instance, which in turn owns its own {{LoginContext}} instance?

[~sershe], could you please comment more about the concrete use case, and 
specifically address why it couldn't be solved with remote users or proxy users?

> 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

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

Reply via email to