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
<img alt="0001-Ticket-49379-Allowed-sasl-mapping-requires-restart.patch" src="/389-ds-base/issue/raw/files/888f686d3c35ab4c7e960e45b2f5e4fbf27ad08e62e3ae47e1b896ff3bd59e54-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)
<img alt="0001-Issue-49379-Add-Python-3-support-to-CI-test.patch" src="/389-ds-base/issue/raw/files/f59a5f2ba7be95b5f5f845db932fec55d882bb87995a2065127f89cd605368e2-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)
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.
<img alt="0001-Issue-49379-Add-Python-3-support-to-CI-test.patch" src="/389-ds-base/issue/raw/files/f48ab2c53e33031ae080f93320326960801e8813870d12ad3ba0f8398e7d9e38-0001-Issue-49379-Add-Python-3-support-to-CI-test.patch" />
Metadata Update from @aadhikari: - Custom field reviewstatus adjusted to review (was: None)
commit 5f3e4be 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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.