> 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:
>
<http://www.stanford.edu/services/directory/openldap/configuration/>
> 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,
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...
So, the SASL library obviously misses out slap_auxprop_lookup, maybe because
in
Sasl_canon_user, the plugin_name is lost and set to INTERNAL...
This all looks like something is either weird, or utterly misconfigured, but
still,
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...)
Regards,
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
Attachment:
slapd.conf
Description: Binary data