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:
rwm-suffixmassage o=example dc=example,dc=com
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)'
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
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.
Show replies by date