zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andor Molnar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-3156) ZOOKEEPER-2184 causes kerberos principal to not have resolved host name
Date Fri, 28 Sep 2018 19:37:00 GMT

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

Andor Molnar commented on ZOOKEEPER-3156:
-----------------------------------------

[~revans2] Thanks for looking into this. As long as you're the assignee of this Jira, I'm
happy to wait for your pull request to review.

Regarding backwards compatibility: "...could run into an issue where each ensemble wants something
different"
This wasn't supported previously either: meaning that previous versions always did reverse
IP lookups, so basically followed the behaviour that you mentioned as 3.4.12. Therefore I
don't think the fix could cause backward compatibility issues as long as the default behaviour
is the original (rnds=true).

Let's try to wrap up what I think happened here:
- Previous versions of ZooKeeper (up to 3.4.12) did DNS resolution upfront and returned the
pure IP address to upper layers like the SASL client. The original implementation stripped
the hostname from the InetSocketAddress after name resolution and created a new one with only
IP address and port number,
- This was fine for connecting the client to the server, because it only needs the IP address,
- It forced the SASL client to do reverse DNS lookup by calling getHostName(),
- The current behaviour, which I think is the right approach, creates new InetSocketAddress
with the resolved IP address and the original hostname, so upper layers don't need to do reverse
lookup.

With the new switch and using getCanonicalHostName() in the SASL client we can enforce the
reverse lookup which is needed here. 

> ZOOKEEPER-2184 causes kerberos principal to not have resolved host name
> -----------------------------------------------------------------------
>
>                 Key: ZOOKEEPER-3156
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3156
>             Project: ZooKeeper
>          Issue Type: Bug
>          Components: java client
>    Affects Versions: 3.6.0, 3.4.13, 3.5.5
>            Reporter: Robert Joseph Evans
>            Assignee: Robert Joseph Evans
>            Priority: Blocker
>
> Prior to ZOOKEEPER-2184 the zookeeper client would canonicalize a configured host name
before creating the SASL client which is used to create the principal name.  After ZOOKEEPER-2184
that canonicalization does not happen so the principal that the ZK client tries to use when
it is configured to talk to a CName is different between 3.4.13 and all previous versions
of ZK.
>  
> For example
>  
> zk1.mycluster.mycompany.com maps to real-node.mycompany.com.
>  
> 3.4.13 will want the server to have [zookeeper/zk1.mycluster.com@KDC.MYCOMPANY.COM|mailto:zookeeper/zk1.mycluster.com@KDC.MYCOMPANY.COM]
> 3.4.12 wants the server to have [zookeeper/real-node.mycompany.com@KDC.MYCOMPANY.COM|mailto:zookeeper/real-node.mycompany.com@KDC.MYCOMPANY.COM]
>  
> This makes 3.4.13 incompatible with many ZK setups currently in existence.  It would
be nice to have that resolution be optional because in some cases it might be nice to have
a single principal tied to the cname.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message