Re: (ITS#6684) Patch for autogroup overlay

[ryans@aweber.com]

I'm not sure if this is still relevant or useful, but included below is a set of steps that will reliably reproduce the
issue and a backtrace using autogroup from HEAD and ppolicy, which as noted causes segmentation faults in the slaptools
utilities (e.g., slapcat).  Note that this backtrace is from a build of 2.4.21, but the issue is present and occurs with
2.4.23 as well, as Norbert has stated.

rgs@ldapmaster3:~# ldapmodify -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy.la

modifying entry "cn=module{0},cn=config"

rgs@ldapmaster3:~# ldapadd -x -h localhost -ZZ -D 'cn=admin,cn=config' -y /etc/ldap.secret
dn: olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {3}ppolicy
olcPPolicyHashCleartext: FALSE
olcPPolicyForwardUpdates: FALSE
olcPPolicyUseLockout: TRUE

adding new entry "olcOverlay={3}ppolicy,olcDatabase={1}hdb,cn=config"

rgs@ldapmaster3:~# cat /etc/ldap/slapd.d/cn=config/cn=module{0}.ldif
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb.la
olcModuleLoad: {1}autogroup.la
olcModuleLoad: {2}syncprov.la
olcModuleLoad: {3}smbk5pwd.la
olcModuleLoad: {4}ppolicy.la
structuralObjectClass: olcModuleList
creatorsName: cn=config
entryUUID: f83e3413-5ba7-4c85-9bf7-ed8728d9fbce
createTimestamp: 20091018205311Z
entryCSN: 20101129205850.805900Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20101129205850Z

rgs@ldapmaster3:~/ldap/ldifs/ppolicy# gdb --args slapcat -n1

(gdb) run
Starting program: /usr/sbin/slapcat -n1
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271
1271	/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c: No such file or directory.
	in /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c
(gdb) backtrace
#0  0x00007ffff2228840 in ppolicy_restrict (op=0x7fffffffd700, rs=0x7fffffffd660) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271
#1  0x00007ffff7f6ed3a in overlay_op_walk (op=0x7fffffffd700, rs=0x7fffffffd660, which=<value optimized out>,
oi=0x7ffff83220c0, on=0x7ffff8341e50)
    at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:659
#2  0x00007ffff7f6f8ab in over_op_func (op=0x7fffffffd700, rs=0xfffffffffffffff0, which=4294957760)
    at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:721
#3  0x00007ffff2846141 in autogroup_db_open (be=<value optimized out>, cr=<value optimized out>) at autogroup.c:1754
#4  0x00007ffff7f6e994 in over_db_open (be=<value optimized out>, cr=0x7fffffffdfb0) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:155
#5  0x00007ffff7f1388c in backend_startup_one (be=0x7ffff8315f80, cr=0x7fffffffdfb0) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:224
#6  0x00007ffff7f13a83 in backend_startup (be=0x7ffff8315f80) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:278
#7  0x00007ffff7f742cc in slap_tool_init (progname=<value optimized out>, tool=2, argc=2, argv=0x7fffffffe5a8)
    at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcommon.c:780
#8  0x00007ffff7f7335a in slapcat (argc=-9536, argv=<value optimized out>) at
/usr/src/openldap/openldap-2.4.21/servers/slapd/slapcat.c:51
#9  0x00007ffff7ee84f5 in main (argc=2, argv=0x7fffffffe5a8) at /usr/src/openldap/openldap-2.4.21/servers/slapd/main.c:657

(gdb) x 0x7fffffffd700
0x7fffffffd700:	0xffffd870

(gdb) x 0x7fffffffd660
0x7fffffffd660:	0x00000000


For reference, line 1271, located within the ppolicy_restrict function, looks like so:

    if ( op->o_conn && !BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) {



-Ryan