version krb5support_0_MIT not defined

[Tom Yu]

Jeff Blaine <jblaine at kickflop.net> writes:

> -bash-3.2# readelf -d /usr/lib64/libcom_err.so 
> /usr/rcf-krb5/lib/libcom_err.so /usr/lib64/libkrb5support.so 
> /usr/rcf-krb5/lib/libkrb5support.so | grep SONAME
>   0x000000000000000e (SONAME)  Library soname: [libcom_err.so.2]
>   0x000000000000000e (SONAME)  Library soname: [libcom_err.so.3]
>   0x000000000000000e (SONAME)  Library soname: [libkrb5support.so.0]
>   0x000000000000000e (SONAME)  Library soname: [libkrb5support.so.0]
> -bash-3.2#
>
> It would appear that I cannot control library location
> preference in this situation, but I am certainly open
> to any last chance suggestions.

I think the solution that I would suggest at this point is using a
wrapper script to start sshd with a value of LD_LIBRARY_PATH that
includes /usr/rcf-krb5/lib, unless there's some specific reason that
you need sshd to use a different set of krb5 libraries than you want
pam_krb5.so to use.

In the long run, there are better ways to overcome the problems you're
experiencing, but they probably require adding new capabilities to the
glibc runtime linker:

* support for RTLD_GROUP

* distinguishing libraries that have the same SONAME but exist as
  distinct files

Solaris supports these; I have heard that the glibc developers have
repeatedly resisted adding these capabilities.

You are expecting pam_krb5.so to resolve the symbols that it needs
using the libraries that it would find in its RPATH.  On a Solaris
system, if sshd had called dlopen() on pam_krb5.so using the
RTLD_GROUP flag, this would be the case.  On RHEL, using the glibc
runtime linker as it currently exists, that does not occur, and
pam_krb5.so will find the versions of the symbols that already exist
in the address space of the sshd process.

In this case on RHEL, the runtime linker actually loads
libcom_err.so.3 into the address space of the sshd process, but this
has minimal practical effect, because the symbols that pam_krb5.so
requires will already bind to the same ones found in the
libcom_err.so.2 that sshd already depended on.  The runtime linker
will not map the /usr/rcf-krb5/lib copy of libkrb5.so.3, because it
has the same SONAME as the /usr/lib copy that sshd depended on, so
your efforts to change the behavior of pam_krb5.so by having it depend
on a more recent version of libkrb5 would not succeed.

> This raises the question to me (largely ignorant past this
> point): Isn't this incorrect?  I'd think that an incompatible
> library issue like this means something was not incremented
> when it should have been, no?

Yes and no.  Shared libraries present some fairly complex
interactions, and some difficult tradeoffs.

The SONAME (the name that the link editor records in dependent
executables and libraries) of the library is something that developers
typically don't increment unless an incompatible change in the
external interface of the library occurs.  Typically this is something
like dramatically altering the interface of an API function, or
deleting interfaces from the library.  Changing the implementation of
the library or adding a new API function aren't normally cause for
incrementing the SONAME.  Changing the SONAME of a library tends to
require distributors of binary packages and operating systems to go
through a lot of effort to manage an orderly transition, so they don't
like library developers to make SONAME changes without a really good
reason.

Here, the OS provides libcom_err.so.2 (from the krb5-1.6.x series,
though a brief check of my sources indicates that we shipped
libcom_err.so.3 at least toward the end of krb5-1.6.x), but
pam_krb5.so declares an explicit dependency on libcom_err.so.3.  The
runtime linker maps libcom_err.so.3 into the sshd address space, but
nothing will reference anything in it (unless something in pam_krb5.so
or its dependencies need to bind to a symbol that libcom_err.so.3
provides but libcom_err.so.2 does not).

I believe the error that you see involves the runtime linker
attempting to resolve all undefined references within libcom_err.so.3,
assuming the call that sshd made to dlopen() included the RTLD_NOW
flag, which forces all symbol binding in the opened shared object to
occur before returning.  Here, libcom_err.so.3 has an undefined
reference to the function symbol "krb5int_strlcpy" with version
"krb5support_0_MIT".  The copy of libkrb5_support.so.0 in /usr/lib
doesn't define this symbol, but the one in /usr/rcf-krb5/lib does.
The two libraries have the same SONAME, so the glibc runtime linker
(unlike Solaris) can't tell them apart when trying to map all the
dependencies.  I believe the Solaris runtime linker would have mapped
both copies of libkrb5_support.so.0 in this case, but it would not
have generally searched the /usr/rcf-krb5/lib versions of the krb5
libraries for symbol resolution unless the call to dlopen() included
the RTLD_GROUP flag, or unless the /usr/lib versions lacked symbols
that the /usr/rcf-krb5/lib versions defined.