25

I read some articles about problems in using the LD_LIBRARY_PATH, even as a part of a wrapper script:

http://linuxmafia.com/faq/Admin/ld-lib-path.html

http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the

In this case - what are the recommended alternatives?

Thanks.

alanc
  • 4,102
  • 21
  • 24
SyRenity
  • 841
  • 5
  • 11
  • 18

4 Answers4

14

You can try adding:

-Wl,-rpath,path/to/lib

to the linker options. This will save you the need to worry about the LD_LIBRARY_PATH environment variable, and you can decide at compile time to point to a specific library.

For a path relative to the binary, you can use $ORIGIN, eg

-Wl,-rpath,'$ORIGIN/../lib'

($ORIGIN may not work when statically linking to shared libraries with ld, use -Wl,--allow-shlib-undefined to fix this)

Community
  • 1
  • 1
Gilad Naor
  • 20,752
  • 14
  • 46
  • 53
  • Yes, there is nothing 'wrong' with LD_LIBRARY_PATH. For a developer running stuff its fine. You would not want to ship product requiring or assuming its use. Instead you would do the above (assuming you actually know where the libraries are going to be). The way to customer proof loading shared libraries is to search every conceivable location and load via dlopen() – EdH Mar 07 '12 at 07:57
  • You probably want to set `--enable-new-dtags` as well e.g. `-Wl,--enable-new-dtags,-rpath,'$ORIGIN/../lib'` – Levi Morrison Oct 26 '17 at 23:11
  • note that if $ORIGIN is used in a makefile, the $ from $ORIGIN needs to be escaped and the extra linker option becomes `-Wl,-rpath,'$$ORIGIN/../lib'` – Manuel Rozier Oct 15 '18 at 14:35
  • also note that you may need to tell the linker to process ORIGIN by adding `-Wl,-z,origin`, see [https://stackoverflow.com/questions/6324131/rpath-origin-not-having-desired-effect](other stackoverflow post) – Manuel Rozier Oct 15 '18 at 14:50
  • +1 for `--allow-shlib-undefined` which accidentally helped me to compile a static version of essential packages. – Alireza Mohamadi Jun 02 '22 at 20:16
7

I've always set LD_LIBRARY_PATH, and I've never had a problem.

To quote you first link:

When should I set LD_LIBRARY_PATH? The short answer is never. Why? Some users seem to set this environment variable because of bad advice from other users or badly linked code that they do not know how to fix.

That is NOT what I call a definitive problem statement. In fact it brings to mind I don't like it. [YouTube, but SFW].

That second blog entry (http://blogs.oracle.com/ali/entry/avoiding_ld_library_path_the) is much more forthcoming on the nature of the problem... which appears to be, in a nutshell, library version clashes ThisProgram requires Foo1.2, but ThatProgram requires Foo1.3, hence you can't run both programs (easily). Note that most of these problems are negated by a simple wrapper script which sets the LD_LIBRARY_PATH for just the executing shell, which is (almost always) a separate child process of interactive shell.

Note also that the alternatives are pretty well explained in the post.

I'm just confused as to why you would post a question containing links to articles which apparently answer your question... Do you have a specific question which wasn't covered (clearly enough) in either of those articles?

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156
corlettk
  • 13,288
  • 7
  • 38
  • 52
6

the answer is in the first article you quoted.

In UNIX the location of a library can be specified with the -L dir option to the compiler. .... As an alternative to using the -L and -R options, you can set the environment variable LD_RUN_PATH before compiling the code.

SpliFF
  • 38,186
  • 16
  • 91
  • 120
  • 1
    @Scoob: LD_RUN_PATH presumes forknowledge of the runtime environment... which is fine if you're building and running on the same machine, but should be avoided for distributable (or even migratable) ELF's... I can't see how specifying LD_RUN_PATH can hurt, but it might not help ;-0 – corlettk May 19 '09 at 11:36
3

I find that the existing answers to not actually answer the question in a straightforward way:

  1. LD_RUN_PATH is used by the linker (see ld) at the time you link your software. It is used only if you have no -rpath ... on the command line (-Wl,rpath ... on the gcc command line). The path(s) defined in that variable are added to the RPATH entry in your ELF binary file. (You can see that RPATH using objdump -x binary-filename—in most cases it is not there though! It appears in my development binaries, but once the final version gets installed RPATH gets removed.)

  2. LD_LIBRARY_PATH is used at runtime, when you want to specify a directory that the dynamic linker (see ldd) needs to search for libraries. Specifying the wrong path could lead to loading the wrong libraries. This is used in addition to the RPATH value defined in your binary (as in 1.)

LD_RUN_PATH really causes no security threat unless you are a programmer and don't know how to use it. As I am using CMake to build my software, the -rpath is used all the time. That way I do not have to install everything to run my software. ldd can find all the .so files automatically. (the automake environment was supposed to do that too, but it was not very good at it, in comparison.)

LD_LIBRARY_PATH is a runtime variable and thus you have to be careful with it. That being said, many shared object would be really difficult to deal with if we did not have that special feature. Whether it is a security threat, probably not. If a hacker takes a hold of your computer, LD_LIBRARY_PATH is accessible to that hacker anyway. What could happen is that you use the wrong path(s) in that variable, your binary may not load, but if it loads you may end up with a crashing binary or at least a binary that does not work quite right. One concern is that over time you get new versions of the library and you are likely to forget to remove the LD_LIBRARY_PATH which means you may be using an unsecure version of the library.

The one other possibility for security is if the hacker installs a fake library of the same name as what the binary is searching, library that includes all the same functions, but that has some of those functions replaced with sneaky code. He can get that library loaded by changing the LD_LIBRARY_PATH variable. Then it will eventually get executed by the hacker. Again, if the hacker can add such a library to your system, he's already in and probably does not need to do anything like that in the first place (since he's in he has full control of your system anyway.) Because in reality, if the hacker can only place the library in his account he won't do anything much (unless your Unix box is not safe overall...) If the hacker can replace one of your /usr/lib/... libraries, he already has full access to your system. So LD_LIBRARY_PATH is not needed.

Alexis Wilke
  • 19,179
  • 10
  • 84
  • 156