You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Jorge Machado (JIRA)" <ji...@apache.org> on 2017/10/27 15:51:00 UTC
[jira] [Commented] (ACCUMULO-4348) Deprecate KerberosToken
constructor that exposes UserGroupInformation
[ https://issues.apache.org/jira/browse/ACCUMULO-4348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16222592#comment-16222592 ]
Jorge Machado commented on ACCUMULO-4348:
-----------------------------------------
I was working on a client with Kerberos. I think we should just should not deprecate the replace user.
I just spend two days trying to see where the error is.
what do you think ?
> 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: 3h 10m
> 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.4.14#64029)