[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 
> Quanah Gibson-Mount
> Gesendet: woensdag 25 augustus 2004 23:33
> An: Guus Leeuw jr.; 'OpenLDAP software list'
> Betreff: Problems with ldapwhoami -> slapd -> segmentation fault
> --On Wednesday, August 25, 2004 9:19 PM +0200 "Guus Leeuw jr." 
> <Guus-Leeuw@gmx.de> wrote:
> >> I suggest reading the list archives for "MIT" and "Heimdal" to see 
> >> why you probably do not want to use MIT Krb5 on top, and should
> >> instead use Heimdal.
> >
> > I'm not too sure though, the problem is with MIT...
> > I rather think the problem is somehow with SASL&slapd or slapd by 
> > itself... Slapd really seems to think (by the sasl2 lib, that it 
> > should open /etc/sasldb2 (which has no use in case of 
> GSSAPI... Or so 
> > the manpage says...) So I guess I am missing some kind of 
> > Configuration to this piece or that piece (not slapd.conf, 
> since that 
> > one seems to go for SASL2... ;)
> >
> > *but* the sample-server and sample-client work together 
> upto the point 
> > Where the client says: Expecting encrypted message (which it says 
> > after It reports authentication OK). Also the saslauthd and 
> > testsaslauthd indicate OK, so I think SASL is not really off...
> >
> > Must be somthing in slapd then?
> Hi Guus,
> Well, I assume you are using SASL/GSSAPI to bind to the 
> server.  That is 
> what we use @ Stanford, and it has been quite solid for me in 
> 2.2.15.  It 
> is fine to use MIT Kerberos with OpenLDAP in a client library 
> setting where 
> threads are not involved.  On the server side, I've found I 
> can routinely 
> kill slapd within about 30 seconds (with segfaults) because 
> MIT as it ships 
> is not thread safe.  You might want to read:

> You may also wish to run slapd with "-d -1" as a parameter to get slapd 
> going with full debugging output, and see where it is segfaulting.  I do 
> strongly suggest either using Heimdal as the Kerberos for the server, or 
> finding Simon's patches (if you search on MIT, you'll find them somewhere)

> for MIT, which I assume he keeps up to date.
> MIT is working actively on the threading issue (I've been doing some 
> testing for them), so hopefully someday this will all be a moot issue.

Turns out after a lot of debugging and stuff, that at one point, slapd
Is calling sasl_server_step, which calls gssapi_server_mech_step with
text->state 3 (SASL_GSSAPI_STATE_SSFREQ). At this point, layerchoice == 4,
Text->requiressf == 0, and text->limitssf == 2147483647 (;).
Then slapd does a canon_user() for AUTHZID | AUTHCID, which after checking
the callback lists, calls slap_sasl_canonicalize(). OK? Ok! ;)
This one canonicalizes leeuwg-t@JUNIOR.HOMENET fine to be
slapAuthcDN="cn=guus leeuw (test),ou=people,dc=junior,dc=homenet".
All fine.
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,
	if(flags & SASL_CU_AUTHZID) {
		_sasl_auxprop_lookup(sconn->sparams, SASL_AUXPROP_AUTHZID,
			oparams->user, oparams->ulen);

The weirdest thing happens here... Although servers/slapd/sasl.c has a
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
And _sasl_conn_getopt will return -1, at which point the stack is so
confused, that
Linux decides the segfault slapd...

So, the SASL library obviously misses out slap_auxprop_lookup, maybe because
Sasl_canon_user, the plugin_name is lost and set to INTERNAL...

This all looks like something is either weird, or utterly misconfigured, but
I don't see why slapd should be segfaulting at this stage?

Anybody any hint??? (I can't see any now :( Stared at it for too long...
Even adding a /user/lib/sasl2/slapd.conf with pwcheck_method:saslauthd did
not do the trick...

I'll attach the slapd.conf, which, for me, is correct (but again: I'm new
for the SASL bit...)


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

Attachment: slapd.conf
Description: Binary data