Bug 110166

Summary: Missing compatibility library for krb5 1.2.7
Product: [Fedora] Fedora Reporter: Sam Varshavchik <mrsam>
Component: krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED CANTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 1CC: jch
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-22 01:04:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sam Varshavchik 2003-11-15 18:46:38 UTC
Description of problem:

After upgrading from Red Hat 9, applications that use krb5 **which
includes all applications that link against OpenSSL, since RH9's
OpenSSL uses krb5** no longer work.

How reproducible:

Always.

Steps to Reproduce:
1. Upgrade RH 9 to FC1.
2. Attempt to invoke any application that linked against either krb5,
or openssl

Actual results:

error while loading shared libraries: libcom_err.so.3: cannot open
shared object file: No such file or directory

Comment 1 Nalin Dahyabhai 2003-11-17 14:50:20 UTC
I don't think this is possible (would that it were).  Some of the
libraries which are required by libssl have changed sonames
(libcom_err), but some have not (libkrb5), and the run-time linker has
nothing more to work with when determining which library to load.

Comment 2 Sam Varshavchik 2003-11-18 00:40:05 UTC
Why, it's very possible!

Executables linked against openssl on RH9 have a direct dependency on
libcom_err.so.3:

# ldd /usr/bin/ssh
        libresolv.so.2 => /lib/libresolv.so.2 (0x4001b000)
        libutil.so.1 => /lib/libutil.so.1 (0x4002d000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40030000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x4003f000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x40054000)
        libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40145000)
        libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3
(0x401a3000)
        libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x401b3000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        libdl.so.2 => /lib/libdl.so.2 (0x401b5000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[root@brimstone root]# strings /usr/bin/ssh | grep libcom_err.so.3
libcom_err.so.3

If this app is not upgraded, it will have an unresolved shared library
dependency in FC1.


Comment 3 Nalin Dahyabhai 2003-11-18 17:09:50 UTC
Yes, so this app must be upgraded, because libcom_err.so.3, which was
part of the krb5-libs package, is no longer there.  The libkrb5.so.3
which is in krb5-libs, and applications which have been linked against
it, now depend on libcom_err.so.2.

If libcom_err.so.3 were to suddenly reappear, applications which
required both libcom_err.so.3 and libkrb5.so.3 would have two versions
of the libcom_err library loaded by the dynamic linker at startup-time
(the one which the application requires, and the one which libkrb5
requires).

Any compatibility solution which leads to loading two versions of the
same library into a given address space will be unstable.

Comment 4 Sam Varshavchik 2003-11-18 23:48:07 UTC
This is now going to be needed for every application that's built
against OpenSSL.  This begs for inclusion in release notes.

libkrb5's soname should've been bumped in FC1, since then binary API
changed.  Just like OpenSSL's soname gets bumped with every minor
point release, due to internal API changes.

Then, applications built on FC1 would've pulled libkrb5.so.4 and
libcom_err.so.2.  Pre-FC1 applications could've used a libkrb5.so.3
and libcom_err.so.3 compatibility libraries.


Comment 5 John Haxby 2004-03-22 16:31:37 UTC
This is a deeply unpleasant feature.   Previously, we've been able to
build on earlier releases and run on later releases provided the right
compatability libraries have been installed.

The fact that libcom_err.so is no longer present and libkrb5.so has
the same version number (.3) as previously would seem to make it very
difficult to get out of this hole.

Although I don't hold out much hope of this being fixable, I really
would like a fix.

Comment 6 ami tabak 2004-05-26 14:19:08 UTC
found a temporary solution, till an offical workaround is released

in the /lib I created a soft link as 
libcom_err.so.3 -> /lib/libcom_err.so.2.1

booted mozilla 1.7 and it worked.

If it works for you as well please add a comment so we can gather data.

Comment 7 John Thacker 2006-04-22 01:04:54 UTC
Not going to be fixed at this point.  Really not going to patch upstream to
change the soname.