[
https://issues.apache.org/jira/browse/HADOOP-12529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14982805#comment-14982805
]
Chris Nauroth commented on HADOOP-12529:
----------------------------------------
Repeating my comment on the mailing list thread:
This sounds like potentially a dangerous change in the general case. If there
are 2 different
Subjects/UGIs with the same principal, but different credentials attached, then
an equality
check on principal alone could cause a get from the FileSystem cache or IPC
client connection
cache to return an instance with incorrect credentials.
This might be just a theoretical concern on my part. For the case of proxy
users, perhaps
an optimization is appropriate, since the proxied user's credentials are not in
play anyway.
bq. Is UserGroupInformation.user OK for comparing?
My concerns above would apply to this proposal too. I think of the Hadoop
{{UserGroupInformation}} class as an abstraction over the JDK {{Subject}} and
the Hadoop {{User}} class as an abstraction over the JDK {{Principal}}. For 2
different instances of {{UserGroupInformation}}/{{Subject}}, even if they have
the same {{User}}/{{Principal}}, they are not necessarily equal if there are
different credentials attached to the 2 instances of
{{UserGroupInformation}}/{{Subject}}. That means there would be at least a
theoretical possibility of introducing bugs related to pulling a {{FileSystem}}
or RPC {{Connection}} out of the cache with the wrong credentials. I don't
know if any code paths really do this, but we need to be wary of it. The
effect of such a bug would be either an incorrect access denied, or worse,
privilege escalation.
> UserGroupInformation equals method depend on the subject object address
> -----------------------------------------------------------------------
>
> Key: HADOOP-12529
> URL: https://issues.apache.org/jira/browse/HADOOP-12529
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Affects Versions: 2.7.1
> Reporter: wangwenli
>
> my question is why UserGroupInformation equals method depend on the
> subject object?
> try below code which is extract from HiveMetaStore:
> {code:title=TestUgi.java|borderStyle=solid}
> UserGroupInformation clientUgi = null;
> UserGroupInformation clientUgi2 = null;
> try {
> clientUgi = UserGroupInformation.createProxyUser("user2",
> UserGroupInformation.getLoginUser());
> clientUgi2 = UserGroupInformation.createProxyUser("user2",
> UserGroupInformation.getLoginUser());
> if (clientUgi.equals(clientUgi2)) {
> System.out.println("==");
> } else {
> System.out.println("!="); // strangely this will be hit
> }
> } catch (IOException e1) {
> e1.printStackTrace();
> }
> {code}
> i found that it is because the equal method from UserGroupInformation
> is compare on subject object ref : subject == ((UserGroupInformation)
> o).subject; .
> as you know, ipc.Client connect to namenode,
> connections.get(ConnectionId) this code will try to reuse the same socket
> to namenode, but because of ConnectionId's equal depend on ugi equal, which
> will cause connections.get(ConnectionId) cann't get the same socket,
> suppose many connect to HiveMetaStore, then many connection to Namenode will
> established.
> so my doubts is why UserGroupInformation is compare on subject object
> ref : subject == ((UserGroupInformation) o).subject, it should compare on
> subject's principal, am i right?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
