accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <>
Subject [jira] [Resolved] (ACCUMULO-3620) Consider removing check on UGI-logged-in user in KerberosToken
Date Mon, 06 Apr 2015 02:47:12 GMT


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:
>             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:
> {}
>   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

View raw message