[jira] [Commented] (KUDU-3297) KRPC connection negotiation fails with RedHat/CentOS cyrus-sasl-gssapi-2.1.27-5 for secure clusters

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

ASF subversion and git services commented on KUDU-3297:
-------------------------------------------------------

Commit fff48ea4e5eadd365a85a05a82f66b3eb76d0b0b in kudu's branch refs/heads/master from Alexey Serbin
[ https://gitbox.apache.org/repos/asf?p=kudu.git;h=fff48ea ]

KUDU-3297 fix RPC negotiations with cyrus-sasl-gssapi-2.1.27-5 and newer

It turns out that setting SASL security properties such as the minimum
Security Strength Factor (SSF) once sasl_client_start() has already
been called isn't working as expected anymore once patch [1] is applied
for the cyrus-sasl-gssapi plugin.

This patch addresses the issue, moving the call to
sasl_setprop(..., SASL_SEC_PROPS, ...) prior to the corresponding call
to sasl_client_start() in the client-side negotiation logic for C++ Kudu
components.

Prior to this patch, GSSAPI-involved scenarios of the negotiation-test
and security-itest would fail when running against the GSSAPI plugin
with patch [1] applied.

With this patch, all scenarios in the negotiation-test and the
security-itest pass.

I didn't add any extra test scenarios since the already existing test
coverage was enough to spot the issue, as it can be seen from above.

[1] https://github.com/cyrusimap/cyrus-sasl/pull/603

Change-Id: Ia655356798c753d5a223933cc09a0731018e10af
Reviewed-on: http://gerrit.cloudera.org:8080/17619
Reviewed-by: Grant Henke <gr...@apache.org>
Reviewed-by: Greg Solovyev <gs...@cloudera.com>
Tested-by: Kudu Jenkins


> 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
>
> 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  This 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 {{2.1.27-3}}).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)