[ 
https://issues.apache.org/jira/browse/ACCUMULO-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-4348.
-----------------------------------------
    Resolution: Fixed

> 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
>
>   Original Estimate: 10m
>          Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> {{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)

Reply via email to