[SENTRY-1737] SentryTransportFactory may use incorrect kerberos principal

• Type: Sub-task
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.0.0
• Fix Version/s: 2.0.0
• Component/s: Sentry
• Assignee: Alex Kolbasov
• Reporter: Alex Kolbasov
• Created: 29/Apr/17 22:15
• Updated: 24/Jul/17 14:52
• Resolved: 10/Jun/17 06:49

Description

The new SentryTransportFactory introduced in SENTRY-1593 has the following code in createTransport():

      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);
      }

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:

      return new UgiSaslClientTransport(SaslRpcServer.AuthMethod.KERBEROS.getMechanismName(),
        serverPrincipalParts[0], serverPrincipalParts[1],
        socket, wrapUgi, conf);

may return a transport with the wrong principal.

Issue Links

• is duplicated by: SENTRY-1777 Generic clients are not able to connect to sentry server with kerberos enabled.
• relates to: SENTRY-1593 Implement client failover for Generic and NN clients
• relates to: SENTRY-1580 Provide pooled client connection model with HA
• relates to: SENTRY-1791 Sentry Clients failover not working with kerberos enabled