Issue 7384 - Assert Crash in ppolicy_ctrls_cleanup
Summary: Assert Crash in ppolicy_ctrls_cleanup
Status: VERIFIED DUPLICATE of issue 9171
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.32
Hardware: All All
: --- normal
Target Milestone: 2.4.50
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-11 18:00 UTC by ghola@rebelbase.com
Modified: 2020-04-28 16:55 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description ghola@rebelbase.com 2012-09-11 18:00:46 UTC
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 ?? ()
Comment 1 Howard Chu 2012-09-27 15:15:39 UTC
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/

Comment 2 ghola@rebelbase.com 2012-09-27 18:02:45 UTC
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

Comment 3 Ryan Tandy 2016-10-12 02:52:08 UTC
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.

Comment 4 OpenLDAP project 2017-04-13 15:17:37 UTC
See also ITS#7966, ITS#6166
Comment 5 Quanah Gibson-Mount 2017-04-13 15:17:37 UTC
changed notes
moved from Incoming to Software Bugs
Comment 6 Ondřej Kuzník 2020-03-25 11:30:25 UTC
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 ***