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

Re: TLS/SSL altNames [was: SSL certificates, kerberos keytabs, and load balancing]

ons, 14.04.2004 kl. 01.22 skrev Medievalist:

> It depends on which "nss_ldap" you're talking about, Tony.



> [root@burner root]# ldd /lib/security/pam_ldap.so
>         libresolv.so.2 => /lib/libresolv.so.2 (0xb75d6000)
> see ->  libldap.so.2 => /usr/lib/libldap.so.2 (0xb75a4000)
> see ->  liblber.so.2 => /usr/lib/liblber.so.2 (0xb7598000)
>         libnsl.so.1 => /lib/libnsl.so.1 (0xb7583000)
>         libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7556000)
>         libpam.so.0 => /lib/libpam.so.0 (0xb754e000)
>         libdl.so.2 => /lib/libdl.so.2 (0xb754a000)
>         libc.so.6 => /lib/tls/libc.so.6 (0xb7412000)
>         libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb73fc000)
>          libssl.so.4 => /lib/libssl.so.4 (0xb73c8000)

Interesting that this'd seem to be from 0.9.6.

>         libcrypto.so.4 => /lib/libcrypto.so.4 (0xb72d7000)
>         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
>         libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0xb72c3000)
>         libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0xb7265000)
>         libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0xb7263000)
>         libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0xb7253000)
>         libz.so.1 => /usr/lib/libz.so.1 (0xb7245000)
> As you can see (if our mailers haven't munged my message to bits) Red Hat's 
> nss_ldap *package* includes pam_ldap, which uses two OL libs.

I'd guess that the segfaults have nothing to do with pam_ldap (segfaults
were all nss or OL related - studying an strace of id closely tends to
confirm this).

> Granted, the nss_ldap *module* doesn't.  Or at least not directly.

nss_ldap-based stuff (id, getent etc.) actually does do binds to slapd
using /etc/ldap.conf.

> What prompted my comment/question was the observation in Bugzilla that this bug 
> occurs in the OpenLDAP 2.0.27 ldapsearch command shipped with Red Hat EL v3.  
> Upgrading the OpenLDAP installation reportedly fixed ldapsearch, but not the 
> related pam_unix + nss_ldap problem, which is described here:
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85728
> One person said that rebuilding the nss_ldap package (therefore recompiling 
> pam_ldap) fixes the problem once you've got OpenLDAP upgraded.  Since Red Hat 
> (and I) statically link these sorts of things, I theorize that OpenLDAP 2.0.27 
> is the culprit.

Most of the contributors to that ITS give indications that this could
mainly be an Openssl lib problem, Strange, because there have been no
Openldap or Openssl 0.9.6 updates of these, if such should be the case.

>From the very beginning of my OL time I've only ever used source code
for OL, Sleepycat, Openssl and Cyrus SASL (I've even compiled my own
pam_ldap on this rig). So even though I'm running RHEL3 I can't really
comment. Though with a sensitive/complicated/partly up2date RHAS3-based
install coming along very soon, I'll definitely bear all this in mind.

Very useful thread :)



Kattekots op de vloer
na de moeë thuiskomst,
weinig walg verwekt.
Getrouw als kind
de kat heet welkom,
wellicht nog knabbels krijgt.

mail: billy - at - billy.demon.nl