Full_Name: Duncan Idaho Version: 2.4.32 OS: Centos 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.148.0.72) We are seeing this a few times a week in our environment. #0 0x0000003874c30265 in raise () from /lib64/libc.so.6 #1 0x0000003874c31d10 in abort () from /lib64/libc.so.6 #2 0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6 #3 0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10, oldctrls=0x11251620) at ppolicy.c:870 #4 0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10) at ppolicy.c:895 #5 0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at result.c:541 #6 0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at result.c:733 #7 0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10) at result.c:860 #8 0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158 #9 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671 #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, which=op_bind) at backover.c:723 #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at backover.c:738 #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0) at op.c:210 #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at op.c:243 #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671 #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, which=op_bind) at backover.c:723 #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at backover.c:738 #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:383 #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205 #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60, arg_v=0x11144d40) at connection.c:1150 #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at connection.c:1286 #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at tpool.c:688 #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0 #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6 #24 0x0000000000000000 in ?? ()
ghola@rebelbase.com wrote: > Full_Name: Duncan Idaho > Version: 2.4.32 > OS: Centos 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.148.0.72) > > > We are seeing this a few times a week in our environment. Can you provide a sample config to reproduce the issue? What is the exact error message on stderr that accompanies this assert? > #0 0x0000003874c30265 in raise () from /lib64/libc.so.6 > #1 0x0000003874c31d10 in abort () from /lib64/libc.so.6 > #2 0x0000003874c296e6 in __assert_fail () from /lib64/libc.so.6 > #3 0x000000000055c369 in ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10, > oldctrls=0x11251620) at ppolicy.c:870 > #4 0x000000000055c4aa in ppolicy_ctrls_cleanup (op=0x11144d40, rs=0x42e3cc10) > at ppolicy.c:895 > #5 0x0000000000442a46 in slap_cleanup_play (op=0x11144d40, rs=0x42e3cc10) at > result.c:541 > #6 0x0000000000443229 in send_ldap_response (op=0x11144d40, rs=0x42e3cc10) at > result.c:733 > #7 0x0000000000443a5d in slap_send_ldap_result (op=0x11144d40, rs=0x42e3cc10) > at result.c:860 > #8 0x000000000052d7d7 in hdb_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:158 > #9 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af8670, on=0x0) at backover.c:671 > #10 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #11 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #12 0x0000000000514136 in relay_back_op (op=0x11144d40, rs=0x42e3cc10, which=0) > at op.c:210 > #13 0x00000000005142b9 in relay_back_op_bind (op=0x11144d40, rs=0x42e3cc10) at > op.c:243 > #14 0x00000000004bc67a in overlay_op_walk (op=0x11144d40, rs=0x42e3cc10, > which=op_bind, oi=0x10af97f0, on=0x0) at backover.c:671 > #15 0x00000000004bc87d in over_op_func (op=0x11144d40, rs=0x42e3cc10, > which=op_bind) at backover.c:723 > #16 0x00000000004bc903 in over_op_bind (op=0x11144d40, rs=0x42e3cc10) at > backover.c:738 > #17 0x000000000045520d in fe_op_bind (op=0x11144d40, rs=0x42e3cc10) at > bind.c:383 > #18 0x000000000045493c in do_bind (op=0x11144d40, rs=0x42e3cc10) at bind.c:205 > #19 0x000000000042cbd4 in connection_operation (ctx=0x42e3cd60, > arg_v=0x11144d40) at connection.c:1150 > #20 0x000000000042d159 in connection_read_thread (ctx=0x42e3cd60, argv=0xc7) at > connection.c:1286 > #21 0x000000000058c6c1 in ldap_int_thread_pool_wrapper (xpool=0x109dfe80) at > tpool.c:688 > #22 0x000000387540673d in start_thread () from /lib64/libpthread.so.0 > #23 0x0000003874cd3d1d in clone () from /lib64/libc.so.6 > #24 0x0000000000000000 in ?? () > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
I'll have to see if I can track down stderr when this happens. Here is the configuration on that host: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/custom.schema include /etc/openldap/schema/ldapux.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/puppet.schema TLSVerifyClient never TLSCertificateFile /etc/openldap/slapd.pem TLSCertificateKeyFile /etc/openldap/slapd.pem TLSCACertificateFile /etc/openldap/ca.pem pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel sync reverse-lookup on # old ACLs include /etc/openldap/legacy.acl # new ACLs include /etc/openldap/new.acl # Allow anonymous access to userPassword for directory binds access to dn.onelevel="ou=users,dc=example2,dc=net" attrs="userPassword" by anonymous auth by self read by * none # Secure unix passwords access to dn.onelevel="ou=users,ou=posix,dc=example2,dc=net" attrs="userPassword" by self read by * none # Secure unix passwords # legacy access to dn.onelevel="ou=people,dc=example,dc=com" attrs="userPassword" by self read by * none access to dn.onelevel="ou=people,dc=example2,dc=net" attrs="userPassword" by self read by * none # posix info is public access to dn.subtree="ou=posix,dc=example2,dc=net" by * read # posix info is public # legacy access to dn.subtree="ou=people,dc=example,dc=com" by * read access to dn.subtree="ou=people,dc=example2,dc=net" by * read access to dn.subtree="ou=group,dc=example2,dc=net" by * read # access to the base dn access to dn.base="dc=example2,dc=net" by * read # access to the base dn # legacy access to dn.base="dc=example,dc=com" by * none # basic access # legacy access to dn.subtree="dc=example,dc=com" by * none # basic access access to * by users read by * none database hdb suffix "dc=example2,dc=net" rootdn "cn=manager,dc=example2,dc=net" rootpw password index objectClass,uidNumber,gidNumber eq index cn,sn,uid,displayName pres,sub,eq index memberUid,mail,givenname eq,subinitial index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryUUID,modifyTimestamp eq index location eq index service subinitial index uniqueMember eq directory /var/lib/ldap sizelimit unlimited cachesize 1000000 idlcachesize 3000000 overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net syncrepl rid=1 provider=ldap://syncrepl.example2.net:389 type=refreshAndPersist searchbase="dc=example2,dc=net" bindmethod=simple binddn=user=sync-user,ou=users,dc=example2,dc=net starttls=critical credentials=password retry="10 100 300 +" database relay suffix "dc=example,dc=com" overlay rwm rwm-suffixmassage "dc=example,dc=com" "dc=example2,dc=net" overlay ppolicy ppolicy_default cn=default,ou=ppolicy,dc=example2,dc=net
Just noting that one way to reproduce this assert reliably is to bind to an existing entry, through the relay, with an incorrect password. The important part of the config is: database mdb suffix dc=example,dc=com [...] overlay ppolicy database relay suffix o=example overlay rwm rwm-suffixmassage o=example dc=example,dc=com overlay ppolicy Then, binding through the relay: $ ldapwhoami -x -D uid=test,o=example -w zzz -e ppolicy slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed. Same as when someone accidentally attaches two ppolicy instances to a single database. Not totally sure, but I suspect it's wrong here too: I don't see what the ppolicy attached to the relay is supposed to add in this case. I guess in theory they could have different configuration? wrt. e.g. ppolicy_use_lockout, or even pwdLockout/pwdMustChange via a different ppolicy_default... Wondering if it would make sense for add_passcontrol to look for a ppolicy control already existing on the op, and try to fail gracefully if so, instead of hitting this on the way out. Binding to the same entry with the correct password... $ ldapwhoami -x -D uid=test,o=example -w test -e ppolicy currently hits the same segfault reported in ITS#7966.
See also ITS#7966, ITS#6166
changed notes moved from Incoming to Software Bugs
Sounds like ITS#9171 - same assert and there are two overlays and both register a response callback. Feel free to reopen otherwise. *** This issue has been marked as a duplicate of issue 9171 ***