Hide Forgot
Description of problem: Once a single character mechanism is in the mech list, the entire list is ignored and all available mechanisms on the systems become available. Version-Release number of selected component (if applicable): cyrus-sasl-2.1.23-13.el6_3.1.x86_64 How reproducible: Steps to Reproduce: 1. Set the sasl mechanisms as "A B DIGEST-MD5" Yes, A and B are not real mechanisms, but they should just be ignored. 2. Check the supported/allowed mechanisms, and all the available mechanisms on the system are listed. However, the expectation is that only DIGEST-MD5 should be available. 3. If you try ""AA BB DIGEST-MD5", then only DIGEST-MD5 is available - which is what should be expected. So its something with single character mechanisms that's throwing things off. Actual results: All available mechanisms are available, when only one valid mech was configured. Expected results: Only validate/configured mechanisms should be available.
Is this supposed to be RHEL-7 bug? I can't reproduce it with cyrus-sasl-2.1.26-13.el7.x86_64. However, it's reproducible on RHEL-6 with cyrus-sasl-2.1.23-13.el6_3.1.x86_64
(In reply to Petr Lautrbach from comment #2) > Is this supposed to be RHEL-7 bug? > > I can't reproduce it with cyrus-sasl-2.1.26-13.el7.x86_64. However, it's > reproducible on RHEL-6 with cyrus-sasl-2.1.23-13.el6_3.1.x86_64 This bug was originally found in Directory Server QE while testing RHEL 7. Version of cyrus-sasl I see there is cyrus-sasl-2.1.26-12.1.el7.x86_64 and I can reproduce the bug. Could you try that one ?
First please try cyrus-sasl-2.1.26-13.el7.x86_64, which is newer than cyrus-sasl-2.1.26-12.1.el7.x86_64. If you are still able to reproduce it, please provide me your reproducer.
Hi, I still have problems with this issue. Installed on RHEL7 system. $ ldapsearch -x -h localhost -p 2222 -D "cn=directory manager" -w Secret123 -LLL -b "" -s base objectclass=* supportedSASLMechanisms dn: supportedSASLMechanisms: EXTERNAL $ ldapmodify -x -h localhost -p 2222 -D "cn=directory manager" -w Secret123 <<EOF dn: cn=config changetype: modify replace: nsslapd-allowed-sasl-mechanisms nsslapd-allowed-sasl-mechanisms: A B C D EOF modifying entry "cn=config" $ ldapsearch -x -h localhost -p 2222 -D "cn=directory manager" -w Secret123 -LLL -b "" -s base objectclass=* supportedSASLMechanisms dn: supportedSASLMechanisms: EXTERNAL supportedSASLMechanisms: ANONYMOUS supportedSASLMechanisms: CRAM-MD5 supportedSASLMechanisms: DIGEST-MD5 $ rpm -qa cyrus-sasl 389-ds-base 389-ds-base-1.3.1.6-15.el7.x86_64 cyrus-sasl-2.1.26-16.el7.x86_64
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
I tried to reproduce it but 389-ds-base in rhel6 (389-ds-base-1.2.11.15-29.el6) doesn't support specifying of nsslapd-allowed-sasl-mechanisms attribute. I tried to reproduce it with sasl2-sample-server but it works correctly. I tried following setup: 1.saslpasswd2 -c testuser 2. cat >/usr/lib64/sasl2/sample.conf <<EOF pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: A B DIGEST-MD5 EOF 3.sasl2-sample-server -p 8000 & 4.sasl2-sample-client -p 8000 localhost authentication with sasl2-sample-client was successful
Given that it was me who switched this bug to rhel-6 and I can confirm comment 13 that it works as expected (for me) I'm closing this bug as works for me in rhel-6. If you have any other information or reproducer which will help us with investigation or fix, feel free to reopen this.