[ 
https://issues.apache.org/jira/browse/ACCUMULO-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Josh Elser resolved ACCUMULO-3620.
----------------------------------
       Resolution: Won't Fix
    Fix Version/s:     (was: 1.7.0)

I think I decided against this. After working on ACCUMULO-3706, I think we have 
sufficient ways to interact with Hadoop's UGI.

> Consider removing check on UGI-logged-in user in KerberosToken
> --------------------------------------------------------------
>
>                 Key: ACCUMULO-3620
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3620
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: client
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>
> Fixing a bunch of tests, I've found that the following is hard to work around:
> {code:title=KerberosToken.java}
>   public KerberosToken() throws IOException {
>     this(UserGroupInformation.getCurrentUser().getUserName());
>   }
> {code}
> It makes the client API harder to manage because you have to be logged in as 
> the user you intend to be acting as. So, things like creating a new user 
> "user" as a different user "root" is non-intuitive.
> Server-side, I know there is at least one place that we construct a 
> KerberosToken which only works because the server is already logged in (but 
> it's just used as a place holder and not as a substitute for some other 
> user's credentials).
> I think we want to remove the check (make it an empty constructor), but I'm 
> not sure what other checks would be desired/necessary to the constructors 
> that accept arguments.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to