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

Re: slapd segfaults with SASL/GSSAPI binds



Oh yeah, here is the gdb backtrace from the crash.  It seems to be
happening in some private bdb function, did I miss a patch somewhere?  I
applied the two patches provided by sleepycat when I downloaded BDB, and
all of the tests completed just fine when I built openldap.

osaka:~# gdb
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-linux".
(gdb) file /usr/local/libexec/slapd
Reading symbols from /usr/local/libexec/slapd...(no debugging symbols
found)...
done.
(gdb) set args -d 256 -h ldap://0.0.0.0 ldaps://0.0.0.0 -u slapd -g
slapd
(gdb) run
Starting program: /usr/local/libexec/slapd -d 256 -h ldap://0.0.0.0
ldaps://0.0.0.0 -u slapd -g slapd
(no debugging symbols found)...[New Thread 1024 (LWP 11811)]
@(#) $OpenLDAP: slapd 2.2.13 (Jul  6 2004 17:17:27) $
       
root@osaka:/usr/local/src/openldap2.2/openldap-2.2.13/servers/slapd
bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December  3,
2003)
bdb_db_init: Initializing BDB database
slapd starting
[New Thread 2049 (LWP 11812)]
[New Thread 1026 (LWP 11813)]
conn=0 fd=15 ACCEPT from IP=192.168.0.3:1311 (IP=0.0.0.0:389)
[New Thread 2051 (LWP 11815)]
conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=0 op=0 SRCH attr=supportedSASLMechanisms
conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=0 op=1 BIND dn="" method=163
 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2051 (LWP 11815)]
0x40075872 in __db_associate_arg ()
   from /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
(gdb) backtrace
#0  0x40075872 in __db_associate_arg ()
   from /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
#1  0x400756aa in __db_associate_pp ()
   from /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
#2  0x406c790d in _nss_db_getspnam_r () from /lib/libnss_db.so.2
#3  0x406c79e0 in _nss_db_getspnam_r () from /lib/libnss_db.so.2
#4  0x406c711e in _nss_db_endservent () from /lib/libnss_db.so.2
#5  0x406c73b3 in _nss_db_getservbyname_r () from /lib/libnss_db.so.2
#6  0x402cca83 in getservbyname_r () from /lib/libc.so.6
#7  0x402cc931 in getservbyname () from /lib/libc.so.6
#8  0x40388211 in krb5_getportbyname () from /usr/lib/libkrb5.so.17
#9  0x4038cdbf in krb5_krbhst_init () from /usr/lib/libkrb5.so.17
#10 0x40393d05 in krb5_sendto_kdc2 () from /usr/lib/libkrb5.so.17
#11 0x40393d81 in krb5_sendto_kdc () from /usr/lib/libkrb5.so.17
#12 0x40387b06 in krb5_get_in_cred () from /usr/lib/libkrb5.so.17
#13 0x40389220 in krb5_get_init_creds_keytab () from
/usr/lib/libkrb5.so.17
#14 0x4036538c in gss_acquire_cred () from /usr/lib/libgssapi.so.1
#15 0x40359fd7 in gssapi_server_mech_step (conn_context=0x817a400,
    params=0x8179c90,
    clientin=0x817a61c
"`\202\002\027\006\t*\206H\206?\022\001\002\002\001",
    clientinlen=539, serverout=0xbf5ff820, serveroutlen=0xbf5ff824,
    oparams=0x81799c0) at gssapi.c:618
#16 0x400ce81e in sasl_server_step (conn=0x8179160,
---Type <return> to continue, or q <return> to quit---
    clientin=0x817a61c
"`\202\002\027\006\t*\206H\206?\022\001\002\002\001",
    clientinlen=539, serverout=0xbf5ff820, serveroutlen=0xbf5ff824)
    at server.c:1359
#17 0x400ce6ca in sasl_server_start (conn=0x8179160, mech=0x817a3f0
"GSSAPI",
    clientin=0x817a61c
"`\202\002\027\006\t*\206H\206?\022\001\002\002\001",
    clientinlen=539, serverout=0xbf5ff820, serveroutlen=0xbf5ff824)
    at server.c:1291
#18 0x08091c4d in slap_sasl_bind ()
#19 0x08076242 in do_bind ()
#20 0x080632df in connection_done ()
#21 0x080c1950 in ldap_pvt_thread_pool_destroy ()
#22 0x401de0ba in pthread_start_thread () from /lib/libpthread.so.0
#23 0x401de101 in pthread_start_thread_event () from
/lib/libpthread.so.0

On Wed, 2004-07-07 at 19:19, Christopher Schadl wrote:
> This is really weird.  I'm just setting up a new server (migrating from
> OpenLDAP 2.0 to 2.2), and slapd segfaults whenever I attempt a SASL bind
> using the GSSAPI mechanism:
> 
> On the client side:
> 
> cds@osaka:~$ kdestroy
> cds@osaka:~$ kinit chris
> chris@LEET.ORG's Password:
> cds@osaka:~$ ldapwhoami
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
> cds@osaka:~$ klist
> Credentials cache: FILE:/tmp/krb5cc_1000
>         Principal: chris@LEET.ORG
>  
>   Issued           Expires          Principal
> Jul  7 18:13:39  Jul  8 04:13:52  krbtgt/LEET.ORG@LEET.ORG
> Jul  7 18:13:39  Jul  8 04:13:52  krbtgt/LEET.ORG@LEET.ORG
> Jul  7 18:13:44  Jul  8 04:13:52  ldap/osaka.leet.org@LEET.ORG
> 
> On the server side:
> 
> osaka:~# /usr/local/libexec/slapd -h ldap://0.0.0.0 ldaps://0.0.0.0 -d
> 256 -u slapd -g slapd
> @(#) $OpenLDAP: slapd 2.2.13 (Jul  6 2004 17:17:27) $
>        
> root@osaka:/usr/local/src/openldap2.2/openldap-2.2.13/servers/slapd
> bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December  3,
> 2003)
> bdb_db_init: Initializing BDB database
> slapd starting
> conn=0 fd=11 ACCEPT from IP=192.168.0.3:1302 (IP=0.0.0.0:389)
> conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
> conn=0 op=0 SRCH attr=supportedSASLMechanisms
> conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
> conn=0 op=1 BIND dn="" method=163
> Segmentation fault
> 
> Here is my (minimal) slapd.conf:
> 
> #
> # See slapd.conf(5) for details on configuration options.
> # This file should NOT be world readable.
> #
> include	    /usr/local/etc/openldap/schema/core.schema
> include     /usr/local/etc/openldap/schema/cosine.schema
> include     /usr/local/etc/openldap/schema/nis.schema
> include     /usr/local/etc/openldap/schema/inetorgperson.schema
> include     /usr/local/etc/openldap/schema/krb5-kdc.schema
> 
> pidfile		/usr/local/var/run/slapd/slapd.pid
> argsfile	/usr/local/var/run/slapd/slapd.args
> 
> TLSCertificateFile      /usr/local/etc/openldap/slapd.crt
> TLSCertificateKeyFile   /usr/local/etc/openldap/slapd.key
> TLSCACertificateFile    /usr/local/etc/openldap/cacert.pem
> 
> sasl-realm  LEET.ORG
> sasl-host   osaka.leet.org
> 
> database	bdb
> suffix		"dc=leet,dc=org"
> rootdn      	"uid=ldapadm,cn=gssapi,cn=auth"
> directory	/usr/local/var/openldap-data
> index		objectClass     eq
> 
> sasl-regexp uid=(.*),cn=gssapi,cn=auth
>     uid=$1,ou=People,dc=leet,dc=org
> 
> Note that Kerberos/GSSAPI is working for other things, and that the
> distinguished name 'uid=chris,ou=People,dc=leet,dc=org' exists in the
> LDAP tree.  My LDAP installation consists of Openldap 2.2.13, linked
> against BDB 4.2.52 and Cyrus SASL 2.1.18.  I'd appreciate any clues as
> to what I might be doing wrong, or if there is a workaround for this
> problem.
> 
> Thanks,
> 
> Chris Schadl
> cschadl@satan.org.uk