Bug 665951 - OpenLDAP slapd(8) with ppolicy crash while replace-deleting userPassword attribute
Summary: OpenLDAP slapd(8) with ppolicy crash while replace-deleting userPassword attr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: openldap
Version: 5.5
Hardware: All
OS: Linux
urgent
high
Target Milestone: rc
: ---
Assignee: Jan Vcelak
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks: 669043
TreeView+ depends on / blocked
 
Reported: 2010-12-28 04:08 UTC by Masahiro Matsuya
Modified: 2018-11-14 15:52 UTC (History)
7 users (show)

Fixed In Version: openldap-2.3.43-16.el5
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2012-02-21 05:28:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
backported patch (4.30 KB, patch)
2011-01-06 04:30 UTC, Masahiro Matsuya
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0155 0 normal SHIPPED_LIVE openldap bug fix and enhancement update 2012-02-20 14:54:48 UTC

Description Masahiro Matsuya 2010-12-28 04:08:36 UTC
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.

Comment 2 Masahiro Matsuya 2011-01-06 04:30:13 UTC
Created attachment 471982 [details]
backported patch

A customer verified the fix with this patch.

Comment 3 Jan Vcelak 2011-01-06 21:00:26 UTC
Thanks! Patch looks good.

Comment 10 Jan Vcelak 2011-01-13 22:42:05 UTC
    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

Comment 11 Jaromir Hradilek 2011-01-18 23:38:51 UTC
    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

Comment 14 masanari iida 2011-12-05 07:46:28 UTC
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.

Comment 15 masanari iida 2011-12-05 07:57:38 UTC
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

Comment 16 Masahiro Matsuya 2011-12-13 06:29:48 UTC
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.

Comment 18 errata-xmlrpc 2012-02-21 05:28:03 UTC
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


Note You need to log in before you can comment on or make changes to this bug.