[
https://issues.apache.org/jira/browse/SENTRY-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16035731#comment-16035731
]
Alexander Kolbasov commented on SENTRY-1737:
--------------------------------------------
Although SENTRY-1580 fixes this, it isn't integrated yet and in the meantime we
want a fix in the current code.
> SentryTransportFactory may use incorrect kerberos principal
> -----------------------------------------------------------
>
> Key: SENTRY-1737
> URL: https://issues.apache.org/jira/browse/SENTRY-1737
> Project: Sentry
> Issue Type: Sub-task
> Components: Sentry
> Affects Versions: sentry-ha-redesign
> Reporter: Alexander Kolbasov
> Assignee: kalyan kumar kalvagadda
> Fix For: sentry-ha-redesign
>
>
> The new {{SentryTransportFactory}} introduced in SENTRY-1593 has the
> following code in {{createTransport()}}:
> {code}
> String serverPrincipal = transportConfig.getSentryPrincipal(conf);
> serverPrincipal = SecurityUtil.getServerPrincipal(serverPrincipal,
> serverAddress.getAddress());
> LOGGER.debug("Using server kerberos principal: " + serverPrincipal);
> if (serverPrincipalParts == null) {
> serverPrincipalParts =
> SaslRpcServer.splitKerberosName(serverPrincipal);
> Preconditions.checkArgument(serverPrincipalParts.length == 3,
> "Kerberos principal should have 3 parts: " + serverPrincipal);
> }
> {code}
> So it caches serverPrincipalParts at the instance level. But the same
> instance can be used to create transports for mutiple destinations which will
> have different server principal, so the following code:
> {code}
> return new
> UgiSaslClientTransport(SaslRpcServer.AuthMethod.KERBEROS.getMechanismName(),
> serverPrincipalParts[0], serverPrincipalParts[1],
> socket, wrapUgi, conf);
> {code}
> may return a transport with the wrong principal.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
