Bug 11963 - Runtime linker isn't respecting LD_RUN_PATH
Summary: Runtime linker isn't respecting LD_RUN_PATH
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ld.so
Version: 6.2
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-06-07 21:55 UTC by eric.ayers
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2000-08-09 02:42:11 UTC
Embargoed:


Attachments (Terms of Use)

Description eric.ayers 2000-06-07 21:55:24 UTC
We are pulling our hair out here over a problem where we are
trying to install multiple versions of the same product in
different directories under /opt.

I pulled down the RPM and I cannot find any information on the order of
precedence at runtime, other than a reference in the ld.so changelog that 
is old old old:


Changes in version 1.6.7:
          ...
        Changed ld-linux.so to use the following order to search 
        for libraries:  LD_{ELF_}LIBRARY_PATH, ld.so.cache, rpath, 
        /usr/lib and /lib.

My problem is this:  the -L option passed on the linker overrides
LD_LIBRARY_PATH at runtime.  In fact, LD_LIBRARY_PATH seems to be
the low man on the totem pole.  -rpath also overrides it. 
This is not in line with the way the run-time linker seems to
work on the other architectures we use, (namely Digital Unix)

In order for my executables to link against the libraries in
the path specified by LD_RUN_PATH, I have to move the
directory where I originally compiled the binaries.  Then, finally
the runtime linker seems to want to take a hint from LD_LIBRARY_PATH 
 
Linux already strips out LD_RUN_PATH and LD_LIBRARY_PATH when you are
running setuid, so I don't really see how this could be a security problem.

Here's some printed evidence of my problem.  My binary is compiled
with -L /opt/dcs/dcs/lib -ldcs (other libraries) -L /opt/dcs/lib (other
libraries). I installed all of my compiled libraries to the
version specific directory /opt/dcs_3.3_t/lib and changed
LD_LIBRARY_PATH to point to them:

eric@uxeric:/bass/home/eric$ echo $LD_LIBRARY_PATH
/opt/dcs_3.3_t/telia_dcs/lib:/opt/dcs_3.3_t/eps/lib:/opt/dcs_3.3_t/lib

eric@uxeric:/bass/home/eric$ export LD_LIBRARY_PATH  
eric@uxeric:/bass/home/eric$ export LD_RUN_PATH=$LD_LIBRARY_PATH

eric@uxeric:/bass/home/eric$ ldd /opt/dcs_3.3_t/dcs/bin/dcs_plan_stat
        libdcs.so => /obj/dcs/dcs/lib/libdcs.so (0x40015000)
        libdcs_dp.so => /obj/dcs/dcs/lib/libdcs_dp.so (0x4021a000)
        libdisk.so => /opt/dcs/disk/lib/libdisk.so (0x4026d000)
        libdict_swap.so => /opt/dcs/dict/lib/libdict_swap.so (0x40277000)
...
        libdl.so.2 => /lib/libdl.so.2 (0x40470000)
        libmenu.so => /opt/dcs/menu/lib/libmenu.so (0x40474000)
        librudp.so => /opt/dcs/ip/lib/librudp.so (0x4047c000)
        librun.so => /opt/dcs/appst/lib/librun.so (0x40488000)
        librpt.so => /opt/dcs/rpt/lib/librpt.so (0x4049a000)
        libfile.so => /opt/dcs/file/lib/libfile.so (0x404a7000)
        libc.so.6 => /lib/libc.so.6 (0x404af000)
        libfree.so => /opt/dcs/lib/libfree.so (0x405a4000)
        libcgisam.so => /opt/dcs/lib/libcgisam.so (0x405b9000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

even though LD_LIBRARY_PATH is set, ldd shows that the executable is
linking against libraries in /opt/dcs/lib.  Now, I move my
development environment libraries out of the way:

eric@uxeric:/bass/home/eric$ mv /opt/dcs /opt/dcs.o
eric@uxeric:/bass/home/eric$ ldd /opt/dcs_3.3_t/dcs/bin/dcs_plan_stat
        libdcs.so => /obj/dcs/dcs/lib/libdcs.so (0x40015000)
        libdcs_dp.so => /obj/dcs/dcs/lib/libdcs_dp.so (0x4021a000)
        libdisk.so => /opt/dcs_3.3_t/lib/libdisk.so (0x4026d000)
...
        libevent.so => /opt/dcs_3.3_t/lib/libevent.so (0x40459000)
        libdl.so.2 => /lib/libdl.so.2 (0x40470000)
        libmenu.so => /opt/dcs_3.3_t/lib/libmenu.so (0x40474000)
        librudp.so => /opt/dcs_3.3_t/lib/librudp.so (0x4047c000)
        librun.so => /opt/dcs_3.3_t/lib/librun.so (0x40488000)
        librpt.so => /opt/dcs_3.3_t/lib/librpt.so (0x4049a000)
        libfile.so => /opt/dcs_3.3_t/lib/libfile.so (0x404a7000)
        libc.so.6 => /lib/libc.so.6 (0x404af000)
        libfree.so => /opt/dcs_3.3_t/lib/libfree.so (0x405a4000)
        libcgisam.so => /opt/dcs_3.3_t/lib/libcgisam.so (0x405b9000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Comment 1 eric.ayers 2000-06-08 13:40:21 UTC
I just noticed something that was inconsistent about what I reported,
the first -L option was -L/obj/dcs/dcs/lib, hence why in the output of
ldd shows them as linking against files in /obj/dcs/dcs/lib instead of
/opt/dcs_3.3_t or /opt/dcs/lib

Also, I am not runinng setuid.

eric@uxeric:/usr/src/redhat/BUILD/ld.so-1.9.5/d-link$ id
uid=209(eric) gid=257(dev) groups=257(dev)


Just for kicks, I export "LD_BIND_NOW" with a value of 1 and that
didn't seem to help either.

Comment 2 eric.ayers 2000-06-08 15:32:46 UTC
... Please close this bug. I have found a way to make this work
and it looks like I was (obviously) confused over the difference between
LD_RUN_PATH and LD_LIBRARY_PATH.  I'll just write down what I believe I
have figured out if anyone else is interested.

ld -rpath <dir> means that the path to find the library is encoded in the
executable and the linker WILL NOT USE LD_LIBRARY_PATH at runtime.  This is
in the man page for ld.

LD_RUN_PATH when used at COMPILE time for making an executable seems to do the
same thing as specifying -rpath to ld. 

I was under the mistaken impression that the LD_RUN_PATH was the same 
as LD_LIBRARY_PATH.

This may not be entirely correct, but what I have observed is that
if you link a shared library and specify -L<dir> -l<someotherlibrary>
that this is also the same as specifying -rpath <dir> on the ld link line.
You can get around this with -rpath-link <dir> which tells the linker
to use <dir> at compile time, but  allow LD_LIBRARY_PATH to work at runtime.

sorry for wasting your time!


Comment 3 Cristian Gafton 2000-08-09 02:42:08 UTC
assigned to jakub


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