[Bug 915995] Re: ldconfig makes system loader /lib/ld-linux.so.2 to be linked to 3rd party loaders in /lib directory

Adam Conrad adconrad at 0c3.net
Sat Oct 6 06:40:46 UTC 2012


ldconfig is doing exactly what it was designed to do, which is to link
SONAMEs to libraries providing that SONAME in the same directory.  This
is more a case of "don't do that, then" than a bug in glibc.

Since there was much asking about why this only happens in recent
versions of Ubuntu, it's because the real linker (ld-2.1x.so) used to
live in /lib until we moved to multiarch so, due to SHEER LUCK because
of sort order, it was scanned first, and subsequent providers of the
SONAME were ignored.  Now that it lives in a different directory, third
party linkers in /lib that provide the incorrect SONAME get picked up
and symlinked.  The solution here is really to not provide the same
SONAME as the system linker, but a quick workaround for those affected
could also be to move the offending third-party binary to the multi-arch
path instead.

** Changed in: eglibc (Ubuntu)
       Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/915995

Title:
  ldconfig makes system loader /lib/ld-linux.so.2 to be linked to 3rd
  party loaders in /lib directory

Status in “eglibc” package in Ubuntu:
  Invalid
Status in “eglibc” package in Debian:
  Fix Released

Bug description:
  Package: libc-bin
  Version: 2.13-0ubuntu13
  Severity: Critical
  Source: eglibc
  Architecture: i386
  System having installed with some 3rd party loaders (ld-<name>.so.x) in /lib directory. With these loaders present if we run ldconfig, its removing the system loader symbolic link ld-linux.so.2 in /lib directory from /lib/i286-linux-gnu/ld-2.13.so and creating the symbolic link to one of the 3rd party loaders(in my case link to ld-nails.so.2) present in /lib directory. As ldconfig not link to proper system loader, system gets unusable and system crashes if we reboot.
  Captured the strace logs for "ldconfig".
  4470  15:25:20 close(4)                 = 0
  4470  15:25:20 stat64("/lib/libhistory.so.6", {st_mode=S_IFREG|0644, st_size=30060, ...}) = 0
  4470  15:25:20 stat64("/lib/libatm.so.1", {st_mode=S_IFREG|0644, st_size=34452, ...}) = 0
  4470  15:25:20 getdents64(3, /* 0 entries */, 32768) = 0
  4470  15:25:20 close(3)                 = 0
  4470  15:25:20 stat64("/lib/libcrypto.so.0.9.8", {st_mode=S_IFREG|0644, st_size=1341364, ...}) = 0
  4470  15:25:20 stat64("/lib/libcrypto.so.0.9.8", {st_mode=S_IFREG|0644, st_size=1341364, ...}) = 0
  4470  15:25:20 stat64("/lib/libatm.so.1", {st_mode=S_IFREG|0644, st_size=34452, ...}) = 0
  4470  15:25:20 stat64("/lib/libatm.so.1.0.0", {st_mode=S_IFREG|0644, st_size=34452, ...}) = 0
  4470  15:25:20 stat64("/lib/libnih-dbus.so.1", {st_mode=S_IFREG|0644, st_size=29984, ...}) = 0
  4470  15:25:20 stat64("/lib/libnih-dbus.so.1.0.0", {st_mode=S_IFREG|0644, st_size=29984, ...}) = 0
  4470  15:25:20 stat64("/lib/libhistory.so.6", {st_mode=S_IFREG|0644, st_size=30060, ...}) = 0
  4470  15:25:20 stat64("/lib/libhistory.so.6.2", {st_mode=S_IFREG|0644, st_size=30060, ...}) = 0
  4470  15:25:20 stat64("/lib/libdevmapper.so.1.02.1", {st_mode=S_IFREG|0644, st_size=137308, ...}) = 0
  4470  15:25:20 stat64("/lib/libdevmapper.so.1.02.1", {st_mode=S_IFREG|0644, st_size=137308, ...}) = 0
  4470  15:25:20 stat64("/lib/libproc-3.2.8.so", {st_mode=S_IFREG|0644, st_size=59108, ...}) = 0
  4470  15:25:20 stat64("/lib/libproc-3.2.8.so", {st_mode=S_IFREG|0644, st_size=59108, ...}) = 0
  4470  15:25:20 stat64("/lib/libfuse.so.2", {st_mode=S_IFREG|0644, st_size=158272, ...}) = 0
  4470  15:25:20 stat64("/lib/libfuse.so.2.8.4", {st_mode=S_IFREG|0644, st_size=158272, ...}) = 0
  4470  15:25:20 stat64("/lib/libxtables.so.5", {st_mode=S_IFREG|0644, st_size=26104, ...}) = 0
  4470  15:25:20 stat64("/lib/libxtables.so.5.0.0", {st_mode=S_IFREG|0644, st_size=26104, ...}) = 0
  4470  15:25:20 stat64("/lib/libssl.so.0.9.8", {st_mode=S_IFREG|0644, st_size=294696, ...}) = 0
  4470  15:25:20 stat64("/lib/libssl.so.0.9.8", {st_mode=S_IFREG|0644, st_size=294696, ...}) = 0
  4470  15:25:20 stat64("/lib/libipq_pic.so.0", {st_mode=S_IFREG|0644, st_size=9688, ...}) = 0
  4470  15:25:20 stat64("/lib/libipq_pic.so.0.0.0", {st_mode=S_IFREG|0644, st_size=9688, ...}) = 0
  4470  15:25:20 stat64("/lib/libparted.so.0", {st_mode=S_IFREG|0644, st_size=425316, ...}) = 0
  4470  15:25:20 stat64("/lib/libparted.so.0.0.1", {st_mode=S_IFREG|0644, st_size=425316, ...}) = 0
  4470  15:25:20 stat64("/lib/libiptc.so.0", {st_mode=S_IFREG|0644, st_size=5212, ...}) = 0
  4470  15:25:20 stat64("/lib/libiptc.so.0.0.0", {st_mode=S_IFREG|0644, st_size=5212, ...}) = 0
  4470  15:25:20 stat64("/lib/libiw.so.30", {st_mode=S_IFREG|0644, st_size=30120, ...}) = 0
  4470  15:25:20 stat64("/lib/libiw.so.30", {st_mode=S_IFREG|0644, st_size=30120, ...}) = 0
  4470  15:25:20 stat64("/lib/ld-linux.so.2", {st_mode=S_IFREG|0755, st_size=117960, ...}) = 0
  4470  15:25:20 stat64("/lib/ld-nails.so.2", {st_mode=S_IFREG|0750, st_size=124720, ...}) = 0
  4470  15:25:20 lstat64("/lib/ld-linux.so.2", {st_mode=S_IFLNK|0777, st_size=25, ...}) = 0
  4470  15:25:20 unlink("/lib/ld-linux.so.2") = 0
  4470  15:25:20 symlink("ld-nails.so.2", "/lib/ld-linux.so.2") = 0
  This issue reproduce only on Ubuntu 11.04. As ldconfig is creating symbolic link causing the system unusable. Want to know why ldconfig is linking to 3rd party loaders instead of system loader ld-2.13.so and appreciate if you could provide the workaround for this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/915995/+subscriptions




More information about the foundations-bugs mailing list