You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Geoffrey Jacoby (JIRA)" <ji...@apache.org> on 2017/01/19 00:14:26 UTC

[jira] [Comment Edited] (PHOENIX-3607) Change hashCode calculation for caching ConnectionQueryServicesImpls

    [ https://issues.apache.org/jira/browse/PHOENIX-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15829028#comment-15829028 ] 

Geoffrey Jacoby edited comment on PHOENIX-3607 at 1/19/17 12:14 AM:
--------------------------------------------------------------------

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 HADOOP-12529 was a proposal to switch the hashing back that several developers argued against. 

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.  


was (Author: gjacoby):
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)