[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