[
https://issues.apache.org/jira/browse/ZOOKEEPER-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17851929#comment-17851929
]
Xin Chen edited comment on ZOOKEEPER-2323 at 6/4/24 2:16 PM:
-------------------------------------------------------------
[~arshad.mohammad] Hi， From ZOOKEEPER-2139, I understand the solution to this
problem, and I summarize it as follows (if there are any errors, please correct
them): Changing the login and initializedLogin from static variables to
non-static can ensure that the login can be re logged every time SaslClient is
created， it is to detect any interaction exceptions with the kerberos, while
avoiding entering the code branch:
{code:java}
“createSaslClient # subject. getPrincipals(). isEmpty().” {code}
Thereby avoiding array out of bounds exceptions and situations where SaslClient
is null.
But this still seems to have issues, it just avoids ZooKeeper clients into
infinite AuthFailedException. NoauthException still exists!
LoginException was thrown through each login, but at this point, a zkclient
without Kerberos authentication was created. Non ACL Znodes can be operated on
in the future. However, when KerberOS recovers from network disconnections and
other anomalies, the previously created zkclient without KerberOS
authentication is still being used without rebuilding the login or recreating a
saslclient. If it is used to operate on ACL Znodes at this time, an error will
always be reported:
{code:java}
KeeperErrorCode = NoAuth for /continuousRunningZKClient，{code}
Isn't this a question that should be considered? And I also met this issue in
ZK-3.6.4，It seems that this issue has not been considered in the updated
version.
I want to know if *the community thinks that this kind of issue needs to be
considered by client-users, and the server only needs to ensure that in the
event of a failure to authenticate with kerberos, a client that can operate on
no acl znode can be created normally. Is that correct？*
*This problem is equivalent to another scenario: when creating a zkClient, the
KerberOS is no longer online, and the created client can only operate on the
Znode of no acl. After the subsequent recovery of the KerberOS, it still
remains the same, and cannot operate on the Znode of ACL, nor does it trigger
the reconstruction of the client*
was (Author: JIRAUSER298666):
[~arshad.mohammad] Hi， From ZOOKEEPER-2139, I understand the solution to this
problem, and I summarize it as follows (if there are any errors, please correct
them): Changing the login and initializedLogin from static variables to
non-static can ensure that the login can be re logged every time SaslClient is
created， it is to detect any interaction exceptions with the kerberos, while
avoiding entering the code branch:
{code:java}
“createSaslClient # subject. getPrincipals(). isEmpty().” {code}
Thereby avoiding array out of bounds exceptions and situations where SaslClient
is null.
But this still seems to have issues, it just avoids ZooKeeper clients into
infinite AuthFailedException. NoauthException still exists!
LoginException was thrown through each login, but at this point, a zkclient
without Kerberos authentication was created. Non ACL Znodes can be operated on
in the future. However, when KerberOS recovers from network disconnections and
other anomalies, the previously created zkclient without KerberOS
authentication is still being used without rebuilding the login or recreating a
saslclient. If it is used to operate on ACL Znodes at this time, an error will
always be reported:
{code:java}
KeeperErrorCode = NoAuth for /continuousRunningZKClient，{code}
Isn't this a question that should be considered? And I also met this issue in
ZK-3.6.4，It seems that this issue has not been considered in the updated
version.
I want to know if *the community thinks that this kind of issue needs to be
considered by client-users, and the server only needs to ensure that in the
event of a failure to authenticate with kerberos, a client that can operate on
no acl znode can be created normally. Is that correct？*
*This problem is equivalent to another scenario: when creating a zkClient, the
KerberOS is no longer online, and the created client can only operate on the
Znode of no acl. After the subsequent recovery of the KerberOS, it still
remains the same, and cannot operate on the Znode of ACL, nor does it trigger
the reconstruction of the client*
> ZooKeeper client enters into infinite AuthFailedException cycle if its unable
> to recreate Kerberos ticket
> ---------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2323
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2323
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
> Affects Versions: 3.4.7, 3.5.1
> Reporter: Mohammad Arshad
> Assignee: Mohammad Arshad
> Priority: Major
> Fix For: 3.5.2
>
> Attachments: ZOOKEEPER-2323-01.patch
>
>
> ZooKeeper client enters into infinite AuthFailedException cycle. For every
> operation its throws AuthFailedException
> Here is the create operation exception
> {code}
> org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode =
> AuthFailed for /continuousRunningZKClient
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
> at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
> at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1753)
> {code}
> This can be reproduced easily with the following steps:
> # Reduce the ZooKeeper client principal max life for example set 2 min. use
> command {color:blue} modprinc -maxlife 2min zkcli {color} in kadmin. (This
> is done to reduce the issue reproduce time)
> # Connect Client to ZooKeeper quorum,let it gets connected and some
> operations are done successfully
> # Disconnect the Client's network, by pulling out the Ethernet cable or by
> any way. Now the Client is in disconnected state, no operation is
> expected,Client tries to reconnect to different-different servers in the
> ZooKeeper quorum.
> # After two minutes Client tries to get new Keberos ticket and it fails.
> # Connect the Client to network. Client comes in connected state but
> AuthFailedException for every operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
