[
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)