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