[
https://issues.apache.org/jira/browse/ZOOKEEPER-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diego Rivera resolved ZOOKEEPER-5030.
-------------------------------------
Release Note:
So.... apparently I'm too dumb to be allowed near complex systems :D
The CVE fix script only replaced the main zookeeper library ... but
zookeeper-jute was also present and not being updated. This caused the issue.
Once that was resolved, everything was happy again.
I apologize for wasting bandwidth. I shall find an appropriate means of
self-flagellation as punishment ... probably with 10 bunched up Cat6e ethernet
cables with insulated plugs.
Cheers.
Resolution: Invalid
> ZooKeeper client lib 3.9.5 now apparently requires JAAS (SASL?) to be
> configured for client connections?
> --------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-5030
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5030
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.9.5
> Environment: Containerized environment, also fails similarly on VMs
> and baremetal.
> Reporter: Diego Rivera
> Priority: Critical
>
> Upon upgrading Artemis's 2.52.0 ZooKeeper library from 3.9.4 to 3.9.5 in
> order to resolve CVE-2026-24281 and CVE-2026-24308, suddenly the Artemis
> instances would not boot up, failing with this error:
> {noformat}
> 2026-03-18 20:22:11,928 INFO [org.apache.zookeeper.ZooKeeper] Initiating
> client connection, connectString=arkcase-zookeeper-0.zookeeper-dns:2181
> sessionTimeout=2000 watcher=org.apache.curator.ConnectionState@2dddc1b9
> 2026-03-18 20:22:11,930 INFO [org.apache.zookeeper.common.X509Util] Setting
> -D jdk.tls.rejectClientInitiatedRenegotiation=true to disable
> client-initiated TLS renegotiation
> 2026-03-18 20:22:11,980 INFO [org.apache.zookeeper.common.X509Util] Default
> TLS protocol is TLSv1.3, supported TLS protocols are [TLSv1.3, TLSv1.2,
> TLSv1.1, TLSv1, SSLv3, SSLv2Hello]
> 2026-03-18 20:22:12,003 INFO [org.apache.zookeeper.ClientCnxnSocket]
> jute.maxbuffer value is 1048575 Bytes
> 2026-03-18 20:22:12,006 INFO [org.apache.zookeeper.ClientCnxn]
> zookeeper.request.timeout value is 0. feature enabled=false
> 2026-03-18 20:22:12,009 DEBUG [org.apache.zookeeper.SaslServerPrincipal]
> Canonicalized address to
> arkcase-zookeeper-0.zookeeper-dns.default.svc.cluster.local
> 2026-03-18 20:22:12,009 INFO
> [org.apache.curator.framework.imps.CuratorFrameworkImpl] Default schema
> 2026-03-18 20:22:12,010 WARN [org.apache.zookeeper.ClientCnxn] SASL
> configuration failed. Will continue connection to Zookeeper server without
> SASL authentication, if Zookeeper server allows it.
> javax.security.auth.login.LoginException: No JAAS configuration section named
> 'Client' was found in specified JAAS configuration file:
> '/app/conf/login.config'.
> at
> org.apache.zookeeper.client.ZooKeeperSaslClient.<init>(ZooKeeperSaslClient.java:192)
> at
> org.apache.zookeeper.ClientCnxn$SendThread.startConnect(ClientCnxn.java:1150)
> at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1200)
> 2026-03-18 20:22:12,010 INFO [org.apache.zookeeper.ClientCnxn] Opening
> socket connection to server
> arkcase-zookeeper-0.zookeeper-dns/10.98.84.41:2181.
> 2026-03-18 20:22:12,011 ERROR [org.apache.curator.ConnectionState]
> Authentication failed
> {noformat}
> The ZooKeeper cluster is NOT (yet) configured to require any sort of
> authentication beyond mTLS, and other clients with older ZooKeeper libraries
> (3.9.4, 3.9.3, 3.8.6) can connect to it quite happily.
> So the question is: why is the ZooKeeper client JAR now requiring the use of
> SASL to connect to the server if this is not being explicitly configured?
> I've double-and-triple-checked the configuration and there's no explicit
> setting of the value zookeeper.sasl.clientconfig anywhere. In fact - it's
> looking for the default value of "Client".
> Any ideas of what could be going on here? Why does the 3.9.5 client require
> authentication that wasn't required before?
> To clarify: if I roll back Artemis to the ZooKeeper 3.9.4 JAR, it works
> perfectly with its existing configuration intact. It's specifically the
> upgrade to 3.9.5 triggers this behavior.
> More context: the reason this is critical is b/c for FedRAMP use we need to
> resolve high-priority CVEs within a very narrow amount of time. We thought we
> had it addressed by upgrading the ZK library to 3.9.5, but that broke things
> further, so we're having to roll back ... I'm def open to workarounds/extra
> configs ... but I couldn't find any guidance on the docs re: how to achieve
> behavior similar to the existing.
> Cheers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
