389-ds-base

#49379 sasl-mechanisms removed during upgrade
Closed: wontfix Opened by firstyear.

Closed: wontfix
Reopen Issue

Description of problem:
sasl-mechanisms removed during upgrade

Once modified sasl mechanisms, RHDS removes all supportedSASLMechanisms after
restarting server.

Version-Release number of selected component (if applicable):
RHEL 7.4

How reproducible:
100%

Steps to Reproduce:

[root@rhds10-2 ~]# ldapsearch -LLL -x -b "" -s base objectclass=*
supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: SCRAM-SHA-1
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: GSS-SPNEGO
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: ANONYMOUS
[root@rhds10-2 ~]# ldapmodify -x -D "cn=Directory manager" 
dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms: EXTERNAL GSSAPI ANONYMOUS
modifying entry "cn=config"
^C
[root@rhds10-2 ~]# ldapsearch -LLL -x -b "" -s base objectclass=*
supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
[root@rhds10-2 ~]# grep -i sasl-mechanisms /etc/dirsrv/slapd-*/dse.ldif
nsslapd-allowed-sasl-mechanisms: EXTERNAL GSSAPI ANONYMOUS
[root@rhds10-2 ~]# stop-dirsrv
Stopping instance "rhds10-2"
[root@rhds10-2 ~]# grep -i sasl-mechanisms /etc/dirsrv/slapd-*/dse.ldif
nsslapd-allowed-sasl-mechanisms: EXTERNAL GSSAPI ANONYMOUS
[root@rhds10-2 ~]# start-dirsrv
Starting instance "rhds10-2"
[root@rhds10-2 ~]# grep -i sasl-mechanisms /etc/dirsrv/slapd-*/dse.ldif
nsslapd-allowed-sasl-mechanisms: EXTERNAL
[root@rhds10-2 ~]# ldapsearch -LLL -x -b "" -s base objectclass=*
supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: ANONYMOUS
[root@rhds10-2 ~]# stop-dirsrv
Stopping instance "rhds10-2"
[root@rhds10-2 ~]# grep -i sasl-mechanisms /etc/dirsrv/slapd-*/dse.ldif
nsslapd-allowed-sasl-mechanisms: EXTERNAL
[root@rhds10-2 ~]# start-dirsrv
Starting instance "rhds10-2"
[root@rhds10-2 ~]# grep -i sasl-mechanisms /etc/dirsrv/slapd-*/dse.ldif
nsslapd-allowed-sasl-mechanisms: EXTERNAL
[root@rhds10-2 ~]# ldapsearch -LLL -x -b "" -s base objectclass=*
supportedSASLMechanisms
dn:
supportedSASLMechanisms: EXTERNAL

Metadata Update from @firstyear:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1486245

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

0001-Ticket-49379-Allowed-sasl-mapping-requires-restart.patch

Metadata Update from @mreynolds:
- Custom field component adjusted to None
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to review
- Custom field type adjusted to None
- Custom field version adjusted to None

@mreynolds. The patch looks good.

Just a question regarding ids_sasl_userdb_checkpass. It use to unlock the backend (BIND_SUCCESS or anonymous). The patch suppress this case and does not unlock the backend. Was it dead code ?

Metadata Update from @tbordaz:
- Custom field reviewstatus adjusted to ack (was: review)

@mreynolds. The patch looks good.
Just a question regarding ids_sasl_userdb_checkpass. It use to unlock the backend (BIND_SUCCESS or anonymous). The patch suppress this case and does not unlock the backend. Was it dead code ?

Exactly, there was a fix done in pw_verify_be_dn() that always unlocks the backend. So in the sasl code it was causing a crash when trying to unlock a backend that was just unlocked.

fbd32c4..c78f41d master -> master

5173add..6927069 389-ds-base-1.3.6 -> 389-ds-base-1.3.6

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue set to the milestone: 1.3.6.0 (was: 0.0 NEEDS_TRIAGE)
- Issue status updated to: Closed (was: Open)

0001-Issue-49379-Add-Python-3-support-to-CI-test.patch

Metadata Update from @aadhikari:
- Custom field reviewstatus adjusted to review (was: ack)

Metadata Update from @spichugi:
- Custom field reviewstatus adjusted to ack (was: review)

Metadata Update from @aadhikari:
- Custom field reviewstatus adjusted to review (was: ack)

Metadata Update from @spichugi:
- Custom field reviewstatus adjusted to ack (was: review)

Sorry mate, undoing the ack.

The better fix is to fix the dsldapobject, not have the test just "mask" the pthon 3 bytes issue.

I'd rather you change src/lib389/lib389/rootdse.py instead.

You can adjust one line to fix this test, rather than many. I think if you do:

    def supported_sasl(self):
        return self.get_attr_vals('supportedSASLMechanisms')
TO
    def supported_sasl(self):
        return self.get_attr_vals_utf8('supportedSASLMechanisms')

There is NEVER a case where ensure_* should be used outside of lib389 core :)

Hope that helps,

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to None (was: ack)

Sorry mate, undoing the ack.
The better fix is to fix the dsldapobject, not have the test just "mask" the pthon 3 bytes issue.
I'd rather you change src/lib389/lib389/rootdse.py instead.

You're right, I've missed it. It's, for sure, the better approach.

0001-Issue-49379-Add-Python-3-support-to-CI-test.patch

Metadata Update from @aadhikari:
- Custom field reviewstatus adjusted to review (was: None)

commit 5f3e4be244e7e41594941a6b69db5f1a37b92df1
To ssh://git@pagure.io/389-ds-base.git
ca855b8..5f3e4be master -> master

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/2438

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: fixed)
Metadata
None
None
None
None
None
review
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.