Re: [nssldap] Segmentation Faults for Ldap Accounts

[Jim Summers <jsummers [at] bachman.cs.ou.edu>]

Andrew Morgan wrote:
> On Thu, 10 Apr 2008, Jim Summers wrote:
>
> > I found the debug parameter in ldap.conf and set it to 1.  Now when I 
> > run commands I can see what is happening.  The interesting part is 
> > that if I run an 'id' command the output from both machines mathces.  
> > But if I run the brightq program I see different debug. For example:
> > Here is the debug from the Fedora 8 running the codehost-config command:
> > ===========
> > ldap_create
> > ldap_url_parse_ext(ldaps://ldap1)
> > ldap_create
> > ldap_url_parse_ext(ldaps://ldap1)
> > ldap_simple_bind
> > ldap_sasl_bind
> > ldap_send_initial_request
> > ldap_new_connection 1 1 0
> > ldap_int_open_connection
> > ldap_connect_to_host: TCP ldap1:636
> > ldap_new_socket: 4
> > ldap_prepare_socket: 4
> > ldap_connect_to_host: Trying 192.10.10.13:636
> > ldap_connect_timeout: fd: 4 tm: 30 async: 0
> > ldap_ndelay_on: 4
> > ldap_is_sock_ready: 4
> > ldap_ndelay_off: 4
> > ===========
> > and at this point the segfault happens.
> >
> > Here it is from the FC6 and the command works:
> >
> > ldap_createldap_url_parse_ext(ldaps://ldap1)
> > ldap_create
> > ldap_url_parse_ext(ldaps://ldap1)
> > ldap_simple_bind
> > ldap_sasl_bind
> > ldap_send_initial_request
> > ldap_new_connection 1 1 0
> > ldap_int_open_connection
> > ldap_connect_to_host: TCP ldap1:636
> > ldap_new_socket: 4
> > ldap_prepare_socket: 4
> > ldap_connect_to_host: Trying 192.10.10.13:636
> > ldap_connect_timeout: fd: 4 tm: 30 async: 0
> > ldap_ndelay_on: 4
> > ldap_is_sock_ready: 4
> > ldap_ndelay_off: 4
> > TLS trace: SSL_connect:before/connect initialization
> > TLS trace: SSL_connect:SSLv2/v3 write client hello A
> > TLS trace: SSL_connect:SSLv3 read server hello A
> > TLS certificate verification: depth: 1, err: 19, subject: /CN=CAcert, 
> > issuer: /CN=CAcert
> > TLS certificate verification: Error, self signed certificate in 
> > certificate chain
> > TLS trace: SSL_connect:SSLv3 read server certificate A
> > TLS trace: SSL_connect:SSLv3 read server done A
> > TLS trace: SSL_connect:SSLv3 write client key exchange A
> > TLS trace: SSL_connect:SSLv3 write change cipher spec A
> > TLS trace: SSL_connect:SSLv3 write finished A
> > TLS trace: SSL_connect:SSLv3 flush data
> > TLS trace: SSL_connect:SSLv3 read finished A
> > ldap_open_defconn: successful
> > ldap_send_server_request
> > .....
> >
> > The output from the id commands on either system matches.
> >
> > Any ideas or suggestions?
>
> Use the ldd command on your brightq binary and on your libnss_ldap.so 
> library.  See if they are referencing different versions of the SSL 
> libraries.  This smells like a library mismatch problem to me.

Here is the output from ldd on the pjm ( brightq ) binary:

ldd pjm
        linux-gate.so.1 =>  (0x00110000)
        libutil.so.1 => /lib/libutil.so.1 (0x004be000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00a92000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00320000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c90000)
        libXi.so.6 => /usr/lib/libXi.so.6 (0x00235000)
        libXext.so.6 => /usr/lib/libXext.so.6 (0x00136000)
        libX11.so.6 => /usr/lib/libX11.so.6 (0x00cd8000)
        libm.so.6 => /lib/libm.so.6 (0x00c65000)
        libc.so.6 => /lib/libc.so.6 (0x00b0a000)
        /lib/ld-linux.so.2 (0x00aeb000)
        libXau.so.6 => /usr/lib/libXau.so.6 (0x00cd3000)
        libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x00ccf000)
        libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00dd6000)
        libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00cc7000)

and from nss_ldap.so:

ldd libnss_ldap.so
        linux-gate.so.1 =>  (0x00110000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00167000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x00180000)
        libssl.so.6 => /lib/libssl.so.6 (0x001ae000)
        libdl.so.2 => /lib/libdl.so.2 (0x001f3000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x001f8000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00211000)
        libc.so.6 => /lib/libc.so.6 (0x00225000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x0037e000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x003b0000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00443000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00469000)
        libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x0046c000)
        libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x00475000)
        libcrypto.so.6 => /lib/libcrypto.so.6 (0x00478000)
        libz.so.1 => /lib/libz.so.1 (0x005ab000)
        /lib/ld-linux.so.2 (0x00aeb000)
        libselinux.so.1 => /lib/libselinux.so.1 (0x005be000)

Could it be that since pjm does not have any of the crypt, sasl, ssl stuff 
compiled in, that it is getting something that is encrypted and can not handle 
it correctly?  If so, how would this be remedied?

I think I am going to look and see if there are compat packages that may be 
missing.

Ideas / Suggestions?

Thanks again

>     Andy

--
Jim Summers
School of Computer Science-University of Oklahoma
-------------------------------------------------