Re: slapcat segfaults when ppolicy overlay added

[Ryan Steele <ryans@aweber.com>]

It appears as though my issue is the same as that which is described in ITS#6684
(http://www.openldap.org/its/index.cgi?findid=6684), which describes an adverse interaction between autogroup and
ppolicy.  I have posted the relevant information (steps to reproduce, backtrace, etc.) in a comment on that ITS.  I am
going to test the patch provided in that ITS by Norbert Pueschel to see if it alleviates the problem.

Ryan Steele wrote:
> Ryan Steele wrote:
>> I've been trying, unsuccessfully, to set up ppolicy in my installation
>> (2.4.21 on Ubuntu).  As soon as I set up the overlay (before I even
>> configure a user with a password policy or set up a default policy),
>> slapcatting the database results in a segmentation fault.  I tried it on
>> 2.4.23 and 2.4.17 with the same results.  Here is the configuration I'm
>> using, and a backtrace from the 2.4.21 installation:
>>
>> 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
>>
>>
>> dn: olcOverlay={3}ppolicy
>> objectClass: olcOverlayConfig
>> objectClass: olcPPolicyConfig
>> olcOverlay: {3}ppolicy
>> olcPPolicyHashCleartext: FALSE
>> olcPPolicyUseLockout: TRUE
>> olcPPolicyForwardUpdates: FALSE
>> structuralObjectClass: olcPPolicyConfig
>>
>>
>> (gdb) run
>> Starting program: /usr/sbin/slapcat -n1
>> [Thread debugging using libthread_db enabled]
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x00007ffff242d840 in ppolicy_restrict (op=0x7fffffffd710,
>> rs=0x7fffffffd670) 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  0x00007ffff242d840 in ppolicy_restrict (op=0x7fffffffd710,
>> rs=0x7fffffffd670) at
>> /usr/src/openldap/openldap-2.4.21/servers/slapd/overlays/ppolicy.c:1271
>> #1  0x00007ffff7f6ed3a in overlay_op_walk (op=0x7fffffffd710,
>> rs=0x7fffffffd670, which=<value optimized out>, oi=0x7ffff8320fc0,
>> on=0x7ffff8340d50)
>>     at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:659
>> #2  0x00007ffff7f6f8ab in over_op_func (op=0x7fffffffd710,
>> rs=0xfffffffffffffff0, which=4294957776)
>>     at /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:721
>> #3  0x00007ffff2a4b141 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=0x7fffffffdfc0) at
>> /usr/src/openldap/openldap-2.4.21/servers/slapd/backover.c:155
>> #5  0x00007ffff7f1388c in backend_startup_one (be=0x7ffff8314e80,
>> cr=0x7fffffffdfc0) at
>> /usr/src/openldap/openldap-2.4.21/servers/slapd/backend.c:224
>> #6  0x00007ffff7f13a83 in backend_startup (be=0x7ffff8314e80) 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=0x7fffffffe5b8)
>>     at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcommon.c:780
>> #8  0x00007ffff7f7335a in slapcat (argc=-9520, argv=<value optimized
>> out>) at /usr/src/openldap/openldap-2.4.21/servers/slapd/slapcat.c:51
>> #9  0x00007ffff7ee84f5 in main (argc=2, argv=0x7fffffffe5b8) at
>> /usr/src/openldap/openldap-2.4.21/servers/slapd/main.c:657
>>
> 
> For reference, the line from ppolicy_restrict() it's segfaulting on (1271) looks like so:
> 
>     if ( op->o_conn && !BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) {
> 
>> As soon as I remove olcOverlay={3}ppolicy from the backend database, the
>> problem disappears.  The configuration isn't anything special so I don't
>> think it's a misconfiguration issue, but I figured I'd get a second
>> opinion from the list before submitting this issue as a bug to the ITS. 
>> As always, all advice and input is appreciated.
>>
>> -Ryan