Description of problem: We are using web based LDAP directory tool phpLDAPAdmin http://phpldapadmin.sourceforge.net/wiki/index.php/Main_Page for our admins and technicians who have rights to administer user accounts. In subsequent text "PLA". Recently we upgraded our LDAP and system to RHEL 5.5 with recent openldap 2.3 (updated to recent patchlevel: 2.3.43-12.el5_5.3) because of password policy module, referential integrity and uid uniquess. We have serious problem when we enable password policy module in the slapd.conf: slapd(8) is crashing if someone tries to "replace" with nothing userPassword attribute in uid-based entry. Additionaly, after crash, LDAP bdb-based database is slightly corrupted and must be exported and re-imported back. When we try to reset userPassword with some other LDAP browser we get err=80 (LDAP internal error) which is ok, because policy does not allow this, but with PLA client, every of our technicians is able to kill master LDAP server process and corrupt the database. PLA tries to "replace" userPassword with null value, while other clients are deleting it from the entry. PLA works ok while LDAP ppolicy is inactive. Daemon slapd(8) must be fixed to give same or similar error when such operation is attempted, and not to crash. We took the librety to examine slapd(8) debugging in the foreground daemon run in "-d -1" all-debug mode, and we found this difference between operations done by PLA and all other clients. ALL OTHER CLIENTS: ---------------------------------------------------------- <<< dnPrettyNormal: <uid=accountcheckhelper,ou=SystemAccounts,ou=System,dc=agrokor,dc=hr>, <uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr> modifications: delete: userPassword no values conn=0 op=3 MOD dn="uid=accountcheckhelper,ou=SystemAccounts,ou=System,dc=agrokor,dc=hr" conn=0 op=3 MOD attr=userPassword slap_global_control: unavailable control: 2.16.840.1.113730.3.4.2 ==> unique_modify <uid=accountcheckhelper,ou=SystemAccounts,ou=System,dc=agrokor,dc=hr> => bdb_entry_get: ndn: "uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr") => bdb_entry_get: found entry: "uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr") => hdb_dn2id("cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => bdb_entry_get: cannot find entry: "cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr" ppolicy_get: using default policy cannot locate modification supplying new password send_ldap_result: conn=0 op=3 p=3 send_ldap_result: err=80 matched="" text="Internal Error" send_ldap_response: msgid=4 tag=103 err=80 ber_flush: 28 bytes to sd 11 0000: 30 1a 02 01 04 67 15 0a 01 50 04 00 04 0e 49 6e 0....g...P....In 0010: 74 65 72 6e 61 6c 20 45 72 72 6f 72 ternal Error daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=1 tvp=zero ldap_write: want=28, written=28 0000: 30 1a 02 01 04 67 15 0a 01 50 04 00 04 0e 49 6e 0....g...P....In 0010: 74 65 72 6e 61 6c 20 45 72 72 6f 72 ternal Error conn=0 op=3 RESULT tag=103 err=80 text=Internal Error ---------------------------------------------------------- PLA: ---------------------------------------------------------- <<< dnPrettyNormal: <uid=accountcheckhelper,ou=SystemAccounts,ou=System,dc=agrokor,dc=hr>, <uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr> modifications: replace: userpassword no values conn=0 op=4 MOD dn="uid=accountcheckhelper,ou=SystemAccounts,ou=System,dc=agrokor,dc=hr" conn=0 op=4 MOD attr=userpassword bdb_dn2entry("uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr") ==> unique_modify <uid=accountcheckhelper,ou=SystemAccounts,ou=System,dc=agrokor,dc=hr> => bdb_entry_get: ndn: "uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr") => bdb_entry_get: found entry: "uid=accountcheckhelper,ou=systemaccounts,ou=system,dc=agrokor,dc=hr" bdb_entry_get: rc=0 => bdb_entry_get: ndn: "cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr" => bdb_entry_get: oc: "(null)", at: "(null)" bdb_dn2entry("cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr") => hdb_dn2id("cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) => bdb_entry_get: cannot find entry: "cn=defpasswordpolicy,ou=policies,ou=system,dc=agrokor,dc=hr" ppolicy_get: using default policy slapd: ../../../../servers/slapd/overlays/ppolicy.c:1567: ppolicy_modify: Assertion `addmod->sml_mod.sm_values != ((void *)0)' failed. Aborted [root@ldap-t1 tmp]# ---------------------------------------------------------- Notice difference between "replace: userpassword \ no values" and "delete: userpassword \ no values" between two sessions. In PLA session, daemon is stone dead, dismissed, while in "delete" example, daemon returns error and continues to work. Version-Release number of selected component (if applicable): openldap-2.3.43-12.el5_5.3 How reproducible: Always Actual results: When slapd receives a replace operation to userPassword with no value, it crashes. Expected results: slapd doesn't crash.
Created attachment 471982 [details] backported patch A customer verified the fix with this patch.
Thanks! Patch looks good.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: - slapd server with ppolicy overlay enabled, trying to delete userPassword attribute - server will crash immediately and may slightly damage the database - applied backported upstream patch targetting this issue - slapd server will not crash when deleting userPassword attribute and perform appropriate action according to ppolicy overlay settings
Technical note updated. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. Diffed Contents: @@ -1,4 +1 @@ -- slapd server with ppolicy overlay enabled, trying to delete userPassword attribute +When running the slapd service with the ppolicy overlay enabled, an attempt to delete the "userPassword" attribute could cause the service to terminate unexpectedly, leaving the database in a corrupted state. With this update, an upstream patch has been applied to address this issue, and deleting the "userPassword" attribute no longer causes the slapd service to crash.-- server will crash immediately and may slightly damage the database -- applied backported upstream patch targetting this issue -- slapd server will not crash when deleting userPassword attribute and perform appropriate action according to ppolicy overlay settings
It seemed patch in comment #2 is already in openldap-2.3.43-12.el5_7.10.src.rpm But "Fixed in version" in this bugzilla page said this is going to be fixed in openldap-2.3.43-16.el5 (which is future version.) And changelog in openldap-2.3.43-12.el5_7.10 doesn't include this bugzilla ID. I want to double check the current status of this case.
In spec file, Patch23: openldap-2.3.43-allow-delete-userpassword.patch Header of the patch explains the patch resolves #665951. > slapd with ppolicy crash while replace-deleting userPassword attribute > (allow delete/replace of userpassword without supplying new one) > > backported upstream patch (1.113), Masahiro Matsuya <mmatsuya> > > Resolves: #665951 > Upstream: ITS #5373
Yes, it was released as an async errata. We are still tracking another package with the same fix for 5.8 here, which is not released yet.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0155.html