Bug 107882 - ldconfig generates incorrect entries in ld.so.cache
ldconfig generates incorrect entries in ld.so.cache
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-10-23 21:00 EDT by Tom
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-26 01:13:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tom 2003-10-23 21:00:41 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030709

Description of problem:
I removed all the ssh and ssl rpms that get installed by Fedora as these
versions are out of date and have known security holes.  I then went to build
and install the latest version of ssl.  This completed successfully and it
installed the the following shared libraries: libcrypto.so.0.9.7 and
libssl.so.0.9.7 in /usr/local/ssl/lib.  I then created the following symbolic
links to these two libraries within the same directory:  libcrypto.so.4 and
libssl.so.4
I then added the path /usr/local/ssl/lib to /etc/ld.so.conf and ran ldconfig so
that it included all the new libraries in ld.so.cache
I then ran the /usr/bin/host command in order to test that the ldconfig command
had worked successfully, because /usr/bin/host needs the shared library
libcrypto.so.4 in order to run.  The host command failed with the following
error: "host: error while loading shared libraries: libcrypto.so.4: cannot open
shared object file: No such file or directory"
The above proceedure has worked perfectly for me on RH 7.1, 7.2, 7.3, 8.0, 9.0
Out of curiosity I copied the /sbin/ldconfig excecutable from a RH 9.0 PC to my
fedora core test3 PC, and ran it.  The /usr/bin/host command then ran perfectly.
It is important to be running the latest versions of ssl and ssh for obvious
reasons, and you can't always wait for rpms to be produced.  So building ssl and
ssh from source code is essential.  Could someone please take a look at the
ldconfig executable that comes with Fedroa core Test3

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Please read my description, the steps to reproduce are clearly spelled out. 

    

Actual Results:  see description

Expected Results:  see description

Additional info:
Comment 1 Ken Snider 2004-02-04 12:02:10 EST
I'm afraid the basis of your beliefs are incorrect.

The openssl/openssh rpm's available from the updates channel (or as
installed if no updates are available) have been patched against all
known security errata. Oftimes redhat will backport a fix to an
earlier openssl/openssh core rather than increment the version,
obviously this has convinced you that these versions were vulnerable
when in fact they are not.

The source RPM's and changelog comments (rpm -q --changelog) include
the details of the patches applied to these versions.
Comment 2 Paul Wiechman 2004-04-29 17:42:14 EDT
I second Tom's observation. I too have run into this bug and exactly
as he described. I even went as far as moving the directory around,
etc. No change. I did get a proper result when creating symbolic links
in /usr/lib for libssl.so.4. I also could make it work when exporting
LD_LIBRARY_PATH with /usr/local/ssl/lib.

The odd thing is that my DB4 libs under /usr/local/db4 where picked up
just fine. The only difference was the libdb-4.xxx.so was not a
symbolic link, while libssl.so.4 was... maybe a clue to the problem?
Comment 3 Jakub Jelinek 2004-04-29 18:08:39 EDT
Please attach ldconfig -p output, ls -l /usr/local/ssl/lib output
and for i in /usr/local/ssl/lib/lib*.so*; do echo $i; readelf -d $i; done
output.
The #1 comment is correct, to my knowledge there are no known security
holes in openss{h,l} packages included in the FC1 updates rpms
(for openssl) or FC1 rpms (in openssh case).
Comment 4 Jakub Jelinek 2004-04-29 18:18:12 EDT
Looking at openssl src.rpm, my guess is that you need
openssl-0.9.7a-soversion.patch patch and you'll be ok then.
ldconfig uses primarily DT_SONAME values.
Comment 5 Josh Bressers 2004-06-18 16:04:38 EDT
Removing security severity; This is not a security issue, it's a
library problem.
Comment 6 Ulrich Drepper 2004-08-26 01:13:25 EDT
No reply in 4 months, closing.  This does not look like any problem in
glibc, but instead as in openssl.  If you ignore patches which are in
the RH versions then don't wonder if something breaks.

Note You need to log in before you can comment on or make changes to this bug.