[
https://issues.apache.org/jira/browse/PHOENIX-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16026838#comment-16026838
]
Hadoop QA commented on PHOENIX-3891:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12870125/PHOENIX-3891.001.patch
against master branch at commit a701600c6a25de5f428fb1a225a5af5a97941924.
ATTACHMENT ID: 12870125
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
45 warning messages.
{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the master's current 0 warnings).
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ private static final String REALM_EQUIVALENCY_WARNING_MSG =
"Provided principal does not contan a realm and the default realm cannot be
determined. Ignoring realm equivalency check.";
+ if (!currentUser.hasKerberosCredentials() ||
!isSameName(currentUser.getUserName(), principal)) {
+ static boolean isSameName(String currentName, String newName, String
hostname, String defaultRealm) throws IOException {
+ newName =
org.apache.hadoop.security.SecurityUtil.getServerPrincipal(newName, hostname);
+ // NB: We _should_ be able to provide our or krb5.conf for this test
to use, but this doesn't
+ // seem to want to play nicely with the rest of the tests. Instead, we
can just provide a default realm
+ assertTrue(ConnectionInfo.isSameName("user/[email protected]",
"user/localhost", null, "APACHE.ORG"));
+ assertFalse(ConnectionInfo.isSameName("user/[email protected]",
"user/localhost", null, "APACHE.ORG"));
+ assertTrue(ConnectionInfo.isSameName("[email protected]",
"[email protected]", null, "APACHE.ORG"));
+ assertTrue(ConnectionInfo.isSameName("user/[email protected]",
"user/[email protected]", null, "APACHE.ORG"));
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/915//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/915//artifact/patchprocess/patchReleaseAuditWarnings.txt
Javadoc warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/915//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/915//console
This message is automatically generated.
> ConnectionQueryServices leak on auto-Kerberos-login without REALM in URL
> ------------------------------------------------------------------------
>
> Key: PHOENIX-3891
> URL: https://issues.apache.org/jira/browse/PHOENIX-3891
> Project: Phoenix
> Issue Type: Bug
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Critical
> Fix For: 4.11.0
>
> Attachments: PHOENIX-3891.001.patch, PHOENIX-3891.002.patch
>
>
> PHOENIX-3189 fixed some logic in construction of a {{ConnectionInfo}} to,
> when requested by the user, perform the Kerberos login and then construct and
> cache the ConnectionInfo->ConnectionQueryServices pair.
> This approach only works when the principal that the user provides in the
> JDBC url is exactly what UGI returns as the short name. Logically equivalent
> principals will result in re-logging in each time and leaking
> ConnectionQueryService instances (and thus HConnection and ZooKeeper objects).
> For example, with Kerberos principals there is a default realm which is
> implied by krb5.conf when not explicitly provided. Thus: {{elserj}} and
> {{elserj@APACHE}} would be considered logically equivalent (when the default
> realm is "APACHE"). We should expand the {{isSameName}} check in
> ConnectionInfo to be a bit smarter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
