accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Slacum (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ACCUMULO-4348) Deprecate KerberosToken constructor that exposes UserGroupInformation
Date Mon, 20 Jun 2016 13:49:05 GMT
William Slacum created ACCUMULO-4348:
----------------------------------------

             Summary: Deprecate KerberosToken constructor that exposes UserGroupInformation
                 Key: ACCUMULO-4348
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4348
             Project: Accumulo
          Issue Type: Improvement
          Components: client, core
    Affects Versions: 1.7.2
            Reporter: William Slacum
            Assignee: William Slacum
            Priority: Trivial
             Fix For: 1.8.0


{{KerberosToken}} works by setting up some metadata about a current user to be validated later
by when a {{UGIAssumingTransport}} is created. The {{public KerberosToken(String principal,
File keytab, boolean replaceCurrentUser) throws IOException}} constructor leaks out the {{UserGroupInformation}}
(or a construct with a similar concept of having mutable, static variables) dependency, by
allowing users to login as a user and hold on to their credentials in a place external to
the token itself. 

While working on ACCUMULO-4306, I was thinking about whether or not this feature/side effect
of {{KerberosToken}} made sense. It is a user convenience thing, but it's not a big convenience,
as logging in as another user isn't complicated (via {{UserGroupInformation}} or standard
Java methodologies. It's also a potential hazard if two threads update the same {{UserGroupInformation}}
class at the same time. 

Without much convenience and concurrency pitfalls, marking this deprecating in 1.8 and removing
in 2.0 makes the most sense.



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

Mime
View raw message