[
https://issues.apache.org/jira/browse/KUDU-3297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458869#comment-17458869
]
ASF subversion and git services commented on KUDU-3297:
-------------------------------------------------------
Commit 519e50faeded50d9f5bdda99627bdafe765f9480 in kudu's branch
refs/heads/branch-1.13.x from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=519e50f ]
KUDU-3297 fix Thrift client used for HMS integration
As it turns out, in the context of KUDU-3297, the SASL negotiation code
needs to be updated in one more place:
src/kudu/thrift/sasl_client_transport.cc
I also thought about unifying the code between the Thrift client
and the RPC code to have a single place to have the correct ordering
between the calls EnableProtection() and sasl_client_start(), but after
some consideration I realized it's not worth it.
As for the testing, I verified that before this patch the following
scenarios in hms_client-test were failing every time when running
on RedHat/CentOS 8.4:
* ProtectionTypes/HmsClientTest.TestHmsOperations/1
* ProtectionTypes/HmsClientTest.TestHmsOperations/3
* ProtectionTypes/HmsClientTest.TestLargeObjects/1
* ProtectionTypes/HmsClientTest.TestLargeObjects/3
The output of the failed test scenarios always contained the following:
Bad status: Runtime error: failed to open Hive Metastore connection:
SASL(-15): mechanism too weak for this user:
With this patch, all scenarios of the hms_client-test pass when running
on RedHat/CentOS 8.4:
This is a follow-up to fff48ea4e5eadd365a85a05a82f66b3eb76d0b0b.
Change-Id: Ic6af12932647eda7092f9f42a57eb211fe31f062
Reviewed-on: http://gerrit.cloudera.org:8080/17958
Tested-by: Kudu Jenkins
Reviewed-by: Bankim Bhavsar <ban...@cloudera.com>
Reviewed-by: Abhishek Chennaka <achenn...@cloudera.com>
Reviewed-by: Attila Bukor <abu...@apache.org>
(cherry picked from commit 0ade8c6f21f0887e90b261ae6b1a57f4a6d1eff1)
Reviewed-on: http://gerrit.cloudera.org:8080/18088
Reviewed-by: Alexey Serbin <aser...@cloudera.com>
Tested-by: Alexey Serbin <aser...@cloudera.com>
> KRPC connection negotiation fails with RedHat/CentOS
> cyrus-sasl-gssapi-2.1.27-5 for secure clusters
> ---------------------------------------------------------------------------------------------------
>
> Key: KUDU-3297
> URL: https://issues.apache.org/jira/browse/KUDU-3297
> Project: Kudu
> Issue Type: Bug
> Components: client, master, rpc, tserver
> Affects Versions: 1.3.0, 1.3.1, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.7.1,
> 1.9.0, 1.10.0, 1.10.1, 1.11.0, 1.12.0, 1.11.1, 1.13.0, 1.14.0, 1.15.0
> Reporter: Alexey Serbin
> Assignee: Alexey Serbin
> Priority: Critical
> Fix For: 1.16.0
>
>
> With the recent RedHat/CentOS 8 update on the {{cyrus-sasl-gssapi}} package,
> Kudu servers and C++ clients can no longer negotiate connections when GSSAPI
> is involved (that's so for secure clusters where Kerberos-based
> authentication is a must). In other words, when the {{cyrus-sasl-gssapi}}
> package is upgraded up to {{2.1.27-5}} version, secure Kudu clusters are no
> longer functional.
> The issue manifests itself by failed RPC connection negotiation with the
> following error logged along with the full connection negotiation trace:
> {noformat}
> Runtime error: SASL(-15): mechanism too weak for this user: Unable to find a
> callback: 32775
> {noformat}
> The breaking change is in the following pull request for cyrus-sasl which has
> been pulled into the {{cyrus-sasl-gssapi-2.1.27-5}} package:
> https://github.com/cyrusimap/cyrus-sasl/pull/603 That patch is named as
> {{cyrus-sasl-2.1.27-Add-support-for-setting-max-ssf-0-to-GSS-SPNEGO.patch}}
> in the SRPM for the {{cyrus-sasl}} package.
> The workaround is to roll back the {{cyrus-sasl-gssapi}} package back to
> {{2.1.27-1}} or earlier versions.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
