version krb5support_0_MIT not defined

[Tom Yu]

Jeff Blaine <jblaine at kickflop.net> writes:

> -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]

This tells me that pam_krb5.so directly lists libcom_err.so.3 as a
dependency, but not libkrb5_support.so.0.  The syslog message could be
coming from the runtime linker as it tries to resolve strlcpy() in the
/usr/rcf-krb5/lib/libcom_err.so.3 that pam_krb5.so depends on.  If the
runtime linker thinks that has already loaded a copy of
libkrb5_support.so.0, it might look in that copy rather than the
correct copy that would be found through the RPATH of libcom_err.so.3.

A lot of this mystery may revolve around whether the runtime linker
has a way to disambiguate different shared libraries that happen to
have the same SONAME but reside in different files and have different
contents.  I've heard it claimed that the Solaris runtime linker
tracks pairs of device numbers with inode numbers to disambiguate
libraries that have the same SONAME, but I don't know if the Linux one
does, and skimming its source code did not make it obvious to me.

> -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#

It appears that sshd also depends directly on libcom_err.so.2, which
is a different SONAME than the libcom_err.so.3 that pam_krb5.so
depends on.  libcom_err.so.2 might or might not depend on
libkrb5_crypto.so.0, but it's possible that some other dependency path
involving the krb5 libraries used by sshd causes the runtime linker to
load the system copy of libkrb5_support.so.0 into the sshd process.

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

Thanks, that will give us information that we can use in attempts to
document this sort of behavior.