[
https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15829028#comment-15829028
]
Geoffrey Jacoby commented on PHOENIX-3607:
------------------------------------------
The discussion in https://issues.apache.org/jira/browse/HADOOP-6670 and
https://issues.apache.org/jira/browse/HADOOP-12529 gives some more context.
HADOOP-6670 introduced the System.Object hashing, and
Apparently the Hadoop developers had concerns with allowing Users with
semantically equal username/subject/principal to count as equal because their
respective UGI objects could have different Credentials attached. They were
apparently worried that caching based on those assumptions could lead to either
access denied errors or privilege escalations from clients getting connections
with the wrong authentication.
> Change hashCode calculation for caching ConnectionQueryServicesImpls
> --------------------------------------------------------------------
>
> Key: PHOENIX-3607
> URL: https://issues.apache.org/jira/browse/PHOENIX-3607
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.8.0, 4.9.0
> Reporter: Geoffrey Jacoby
> Assignee: Geoffrey Jacoby
>
> PhoenixDriver maintains a cache of ConnectionInfo ->
> ConnectionQueryServicesImpl (each of which holds a single HConnection) :
> The hash code of ConnectionInfo in part uses the hash code of its HBase User
> object, which uses the *identity hash* of the Subject allocated at login.
> There are concerns about the stability of this hashcode. When we log out and
> log in after TGT refresh, will we have a new Subject?
> To be defensive, we should do a hash of the string returned by user.getName()
> instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
