Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Tue, 24 Feb 2015 17:14:04 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12777220.1424798038000.2339.1424798044656@Atlassian.JIRA>
In-Reply-To: <JIRA.12777220.1424798038000@Atlassian.JIRA>
References: <JIRA.12777220.1424798038000@Atlassian.JIRA>
 <JIRA.12777220.1424798038255@arcas>
Subject: [jira] [Created] (ACCUMULO-3620) Consider removing check on
 UGI-logged-in user in KerberosToken
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Josh Elser created ACCUMULO-3620:
------------------------------------

             Summary: 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
             Fix For: 1.7.0


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)