[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