[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
AW: Problems with ldapwhoami -> slapd -> segmentation fault
> Von: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org] Im Auftrag von
> Guus Leeuw jr.
> Gesendet: maandag 30 augustus 2004 0:52
> An: 'OpenLDAP software list'
> Betreff: AW: Problems with ldapwhoami -> slapd -> segmentation fault
>
> Then back in _sasl_canon_user(), there is a section which says
> #ifndef macintosh
> /* do auxprop lookups (server only) */
> If(sconn) {
> if(flags & SASL_CU_AUTHID) {
> _sasl_auxprop_lookup(sconn->sparams, 0, oparams->authid,
> oparams->alen);
> }
> if(flags & SASL_CU_AUTHZID) {
> _sasl_auxprop_lookup(sconn->sparams,
> SASL_AUXPROP_AUTHZID,
> oparams->user, oparams->ulen);
> }
> }
> #endif
>
> The weirdest thing happens here... Although servers/slapd/sasl.c has a
> function
> Slap_auxprop_lookup(), this one never gets called...
> Instead, _sasl_canon_user() calls _sasl_auxprop_lookup() for authid
> leeuwg-t@JUNIOR.HOMENET, which calls _sasl_getcallback,
> resulting in the
> Library default _sasl_conn_getopt(). This, then, is called,
> loosing the
> plugin_name (??), and falls through to look in the config file
> (sasl_config_getstring()) for a key named "auxprop_plugin",
> which it cannot
> find,
> And _sasl_conn_getopt will return -1, at which point the stack is so
> confused, that
> Linux decides the segfault slapd...
Found 1 spot during initialization, where slapd is not looking up the
Return code from sasl_auxprop_add_plugin().
Patch sent to openldap-devel.
Doesn't help, but I guess cleaning up on the stack is not bad either... ;)
Guus
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.712 / Virus Database: 468 - Release Date: 27/06/2004