version krb5support_0_MIT not defined

Jeff Blaine jblaine at kickflop.net
Wed Feb 8 09:32:37 EST 2012


First, thanks to everyone helping unravel this mystery.

On 2/7/2012 6:52 PM, Tom Yu wrote:
> Jeff Blaine<jblaine at kickflop.net>  writes:
>
>> Here's my understanding of what is happening:
>>
>> sshd -->  pam_krb5.so  (*)
>>               |
>>               |-->  /usr/rcf-krb5/lib/libcom_err.so.3   (**)
>>                           |
>>                           |-->  /usr/lib64/libkrb5support.so.0  (***)
>
> How did you determine which path was actually used to find
> libkrb5support.so.0?

Proven, no, but it was based on this:

-bash-3.2# ldconfig -p | grep krb5support | head -1
         libkrb5support.so.0 (libc6,x86-64) => 
/usr/lib64/libkrb5support.so.0
-bash-3.2#

>> All built with LDFLAGS="-Xlinker -rpath -Xlinker /usr/rcf-krb5/lib"
>>
>> * Our module, not stock RHEL.
>> ** Being found properly as /usr/rcf-krb5/lib/libcom_err.so.3,
>>      according to syslog line above.
>> *** WTF
>>
>> I just spent another hour on this, and it just makes no
>> sense to me.  I can see all of the proper runtime linker
>> path info right in the output of make for both MIT
>> Kerberos 1.9.2 and the PAM module.  It all shows up in
>> 'readelf -d' output too.
>
> What are the direct dependencies listed by "readelf -d" for sshd and
> pam_krb5.so?  (the "NEEDED" lines)

-bash-3.2# readelf -d /lib64/security/pam_krb5.so | grep NEEDED
  0x0000000000000001 (NEEDED)    Shared library: [libkrb5.so.3]
  0x0000000000000001 (NEEDED)    Shared library: [libk5crypto.so.3]
  0x0000000000000001 (NEEDED)    Shared library: [libcom_err.so.3]
  0x0000000000000001 (NEEDED)    Shared library: [libkeyutils.so.1]
  0x0000000000000001 (NEEDED)    Shared library: [libresolv.so.2]
  0x0000000000000001 (NEEDED)    Shared library: [libdl.so.2]
  0x0000000000000001 (NEEDED)    Shared library: [libpam.so.0]
  0x0000000000000001 (NEEDED)    Shared library: [libc.so.6]
-bash-3.2# readelf -d /usr/sbin/sshd | grep NEEDED
  0x0000000000000001 (NEEDED)    Shared library: [libwrap.so.0]
  0x0000000000000001 (NEEDED)    Shared library: [libpam.so.0]
  0x0000000000000001 (NEEDED)    Shared library: [libdl.so.2]
  0x0000000000000001 (NEEDED)    Shared library: [libselinux.so.1]
  0x0000000000000001 (NEEDED)    Shared library: [libaudit.so.0]
  0x0000000000000001 (NEEDED)    Shared library: [libfipscheck.so.1]
  0x0000000000000001 (NEEDED)    Shared library: [libcrypto.so.6]
  0x0000000000000001 (NEEDED)    Shared library: [libutil.so.1]
  0x0000000000000001 (NEEDED)    Shared library: [libz.so.1]
  0x0000000000000001 (NEEDED)    Shared library: [libnsl.so.1]
  0x0000000000000001 (NEEDED)    Shared library: [libcrypt.so.1]
  0x0000000000000001 (NEEDED)    Shared library: [libresolv.so.2]
  0x0000000000000001 (NEEDED)    Shared library: [libgssapi_krb5.so.2]
  0x0000000000000001 (NEEDED)    Shared library: [libkrb5.so.3]
  0x0000000000000001 (NEEDED)    Shared library: [libk5crypto.so.3]
  0x0000000000000001 (NEEDED)    Shared library: [libcom_err.so.2]
  0x0000000000000001 (NEEDED)    Shared library: [libnss3.so]
  0x0000000000000001 (NEEDED)    Shared library: [libc.so.6]
-bash-3.2#

>> For some reason I cannot begin to explain, the MIT
>> libcom_err.so.3 is seeking libkrb5support.so.0 and
>> refuses to find it sitting right where it was told
>> to look.
>
> It's possible that setting the LD_DEBUG environment variable to "libs"
> would give you more useful information about the shared library search
> paths.  You might need to point LD_DEBUG_OUTPUT somewhere useful so it
> won't send the debug output to stderr.

I'm going to fire up an sshd -d -o "Port 2222" with LD_DEBUG=libs
and will report back with any findings.


More information about the Kerberos mailing list