[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6572) slapd crash caused by refint's cn=config modification



Hi Matthew,


I've tested your patch against HEAD and there seems to be a bug left 
open within (or even newly introduced by?) your patch:

I've added Quanah into cc as his Call for 2.4.43RE testing seems to 
depend on this ITS.


Executive summary: ;-)
======================

*** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): 
invalid pointer: 0x09d507d8 ***


Technical details: ;-)
======================

If I remove the following refint configuration directive from 
cn=config's refint-ldif file:

olcRefintModifiersName: 
uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f
  oo,dc=bar

slaptest & slapd both startup fine. If the above statement is contained 
in the current configuration it results in an "invalid pointer" crash 
during slaptest and also during slapd startup (see below)...


Cheers
Daniel



ldif_read_file: read entry file: 
"slapd.d/cn=config/olcDatabase={2}hdb/olcOverlay={4}refint.ldif"
=> str2entry: "dn: olcOverlay={4}refint
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
olcOverlay: {4}refint
olcRefintAttribute: secretary
olcRefintAttribute: manager
olcRefintAttribute: roleOccupant
olcRefintAttribute: member
olcRefintAttribute: memberOf
olcRefintAttribute: owner
olcRefintNothing: 
uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=
  bar
olcRefintModifiersName: 
uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f
  oo,dc=bar
structuralObjectClass: olcRefintConfig
entryUUID: ac810092-0b82-102f-9080-ed6f5f0ebf63
creatorsName: cn=config
createTimestamp: 20100613215924Z
entryCSN: 20100614121813.528580Z#000000#000#000000
modifiersName: cn=ldapmanager,cn=config
modifyTimestamp: 20100614121813Z
"
 >>> dnPrettyNormal: <olcOverlay={4}refint>
<<< dnPrettyNormal: <olcOverlay={4}refint>, <olcOverlay={4}refint>
 >>> dnPretty: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
<<< dnPretty: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
 >>> dnPretty: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
<<< dnPretty: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
 >>> dnPretty: <cn=config>
<<< dnPretty: <cn=config>
 >>> dnNormalize: <cn=config>
<<< dnNormalize: <cn=config>
 >>> dnPretty: <cn=ldapmanager,cn=config>
<<< dnPretty: <cn=ldapmanager,cn=config>
 >>> dnNormalize: <cn=ldapmanager,cn=config>
<<< dnNormalize: <cn=ldapmanager,cn=config>
<= str2entry(olcOverlay={4}refint) -> 0x9cd6a04
 >>> dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
<<< dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, 
<uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
 >>> dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
<<< dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, 
<uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
 >>> dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
<<< dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, 
<uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
 >>> dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
<<< dnPrettyNormal: 
<uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, 
<uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>
*** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): 
invalid pointer: 0x09d507d8 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6(+0x6b321)[0xb735c321]
/lib/i686/cmov/libc.so.6(+0x6cb78)[0xb735db78]
/lib/i686/cmov/libc.so.6(cfree+0xAborted


Matthew Backes schrieb:
> Here's a patch that fixes 6572.
> 
> * Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead
> * Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial)
> * Should apply cleanly to RE24 and HEAD
> * Older dyn-config refints (RE22, RE23) likely have the same problem
> 
> Matthew Backes
> Symas Corporation
> mbackes@symas.com
> 
>