[Bug 920942] [NEW] ldconfig makes system loader ld-linux.so.2 to be link to 3rd party loader resides in /lib directory on Ubuntu 11.04

Venkatesh 920942 at bugs.launchpad.net
Tue Jan 24 12:15:38 UTC 2012


Public bug reported:

ldconfig unlink or removes the existing system loader ld-linux.so that
was linked to /lib/i386-linux-gnu/ld-2.13.so and creates symlink with
3rd party loader which resides in /lib/ld-.so, This creates system
unusable and gets kernel panic on reboot. This ldconfig behavior can be
reproduced when I was doing any pkg installation or upgrade system using
apt-get install(Only when 3rd party loaders say for ex. ld-.so present
in /lib directory)

Simple General  steps to reproduce:
------------------------------------------------------
1) Create shared library loader  ld-test.so.2 providing SONAME of system loader that is "ld-linux.so.2"  and copy loader ld-test.so.2 to  /lib directory
2) Now just run command "ldconfig"
3) after completing ldconfig system is in unusable state that means no commands work, workaround for commands to work is to set LD_LIBRARY_PATH="/lib/i386-linux-gnu" . But  kernel panic occurs if we reboot system.

I looked into this issue and then found that what apt-get install is
doing and came to know that the ldconfig which is doing this symbolic
link to 3rd party loader. Then I gone through ldconfig source code
(glibc 2.13) and understood little bit of ldconfig algorithm and came to
know that the ldconfig basically searches based on SONAME of each
library,Checked our 3rd party library SONAME using "readelf -d
/lib/ld-.so.2" utility.

As 3rd party loader ld-.so and system loader /li/ld-linux.so.2 has same
SONAME, I am thinking this is causing the ldconfig to link to 3rd party
loader. Not sure exactly thats why I have created simple shared library
which is having same SONAME as the system loader having and tested the
system upgrade using apt-get and then I have encountered into same
issue(system unusable) and apt-get upgrade works fine without any issues
after creating loader with different SONAME.

But as other versions (Ubuntu 10.xx)or different distribution
(RHEl,SLES)of linux works fine with this 3rd party loader having same
SONAME, only on this Ubuntu 11.04 creating problem. How is it
functioning different here?Is there any specific change with respect to
ldconfig loading/linking of 3rd party loaders kept in /lib directory? or
having similar SONAME for both loaders creating this problem, if yes
then why its not happening on earlier versions? Which is the better
place/path in the system to keep 3rd party loaders both in case of a
public or private?

Hope above info is enough to understand the issue and appreciate your kind help on this issue.
Please let me know in case if you require any more info.

Thanks and Regards
Venkatesh Prasad C
venkiprs at gmail.com

** Affects: eglibc (Ubuntu)
     Importance: Undecided
         Status: New

-- 
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/920942

Title:
  ldconfig makes system loader ld-linux.so.2 to be link to 3rd party
  loader resides in /lib directory on Ubuntu 11.04

Status in “eglibc” package in Ubuntu:
  New

Bug description:
  ldconfig unlink or removes the existing system loader ld-linux.so that
  was linked to /lib/i386-linux-gnu/ld-2.13.so and creates symlink with
  3rd party loader which resides in /lib/ld-.so, This creates system
  unusable and gets kernel panic on reboot. This ldconfig behavior can
  be reproduced when I was doing any pkg installation or upgrade system
  using apt-get install(Only when 3rd party loaders say for ex. ld-.so
  present in /lib directory)

  Simple General  steps to reproduce:
  ------------------------------------------------------
  1) Create shared library loader  ld-test.so.2 providing SONAME of system loader that is "ld-linux.so.2"  and copy loader ld-test.so.2 to  /lib directory
  2) Now just run command "ldconfig"
  3) after completing ldconfig system is in unusable state that means no commands work, workaround for commands to work is to set LD_LIBRARY_PATH="/lib/i386-linux-gnu" . But  kernel panic occurs if we reboot system.

  I looked into this issue and then found that what apt-get install is
  doing and came to know that the ldconfig which is doing this symbolic
  link to 3rd party loader. Then I gone through ldconfig source code
  (glibc 2.13) and understood little bit of ldconfig algorithm and came
  to know that the ldconfig basically searches based on SONAME of each
  library,Checked our 3rd party library SONAME using "readelf -d
  /lib/ld-.so.2" utility.

  As 3rd party loader ld-.so and system loader /li/ld-linux.so.2 has
  same SONAME, I am thinking this is causing the ldconfig to link to 3rd
  party loader. Not sure exactly thats why I have created simple shared
  library which is having same SONAME as the system loader having and
  tested the system upgrade using apt-get and then I have encountered
  into same issue(system unusable) and apt-get upgrade works fine
  without any issues after creating loader with different SONAME.

  But as other versions (Ubuntu 10.xx)or different distribution
  (RHEl,SLES)of linux works fine with this 3rd party loader having same
  SONAME, only on this Ubuntu 11.04 creating problem. How is it
  functioning different here?Is there any specific change with respect
  to ldconfig loading/linking of 3rd party loaders kept in /lib
  directory? or having similar SONAME for both loaders creating this
  problem, if yes then why its not happening on earlier versions? Which
  is the better place/path in the system to keep 3rd party loaders both
  in case of a public or private?

  Hope above info is enough to understand the issue and appreciate your kind help on this issue.
  Please let me know in case if you require any more info.

  Thanks and Regards
  Venkatesh Prasad C
  venkiprs at gmail.com

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




More information about the foundations-bugs mailing list