Bug 1040699

Summary: The mechanism list isn't properly handled when single characters mechanisms are provided
Product: Red Hat Enterprise Linux 6 Reporter: mreynolds
Component: cyrus-saslAssignee: Petr Lautrbach <plautrba>
Status: CLOSED WORKSFORME QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: dspurek, jrusnack, ksrot, mkubik, pvrabec
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1089267 (view as bug list) Environment:
Last Closed: 2014-06-23 09:32:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1070830, 1089267    

Description mreynolds 2013-12-11 22:42:32 UTC
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.

Comment 2 Petr Lautrbach 2014-01-07 16:07:48 UTC
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

Comment 4 Ján Rusnačko 2014-01-13 18:58:58 UTC
(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 ?

Comment 5 Petr Lautrbach 2014-01-14 08:03:05 UTC
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.

Comment 6 Milan Kubík 2014-01-24 16:53:20 UTC
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

Comment 12 RHEL Program Management 2014-04-15 12:41:33 UTC
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.

Comment 13 David Spurek 2014-04-18 13:17:11 UTC
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

Comment 16 Petr Lautrbach 2014-06-23 09:32:12 UTC
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.