X

LD_LIBRARY_PATH - just say no

By: Rod Evans

A recent email discussion reminded me of how fragile, and prevalent, LD_LIBRARY_PATH use it. Within a development environment, this variable is very useful. I use it all the time to experiment with new libraries.

But within a production environment, use of this environment variable can be problematic. See Directories Searched by the Runtime Linker in the Linkers and Libraries Guide for an overview of LD_LIBRARY_PATH use at runtime.People use this environment variable to establish search paths for applications whose dependencies do not reside in constant locations. Sometimes wrapper scripts are employed to set this variable, other times users maintain an LD_LIBRARY_PATH within their .profile. This latter model can often get out of hand - try running:

    % ldd -s /usr/bin/date
    ...
    find object=libc.so.1; required by /usr/bin/date
     search path=/opt/ISV/lib (LD_LIBRARY_PATH)

If you have a large number of LD_LIBRARY_PATH components specified, you'll see libc.so.1 being wastefully searched for, until it is finally found in /usr/lib. Excessive LD_LIBRARY_PATH components don't help application startup performance.

Wrapper scripts attempt to compensate for inherited LD_LIBRARY_PATH use. For example, a version of acroread reveals:

LD_LIBRARY_PATH="`prepend "$ACRO_INSTALL_DIR/$ACRO_CONFIG/lib:\ 
    $ACRO_INSTALL_DIR/$ACRO_CONFIG/lib" "$LD_LIBRARY_PATH"`

The script is prepending its LD_LIBRARY_PATH requirement to any inherited definition. Although this provides the necessary environment for acroread to execute, we're still wasting time looking for any system libraries in the acroread sub-directories.

When 64-bit binaries came along, we had a bit of a dilemma with how to interpret LD_LIBRARY_PATH. But, because of its popularity, it was decided to leave it applicable to both class of binaries (64 and 32-bit), even though its unusual for a directory to contain both 64 and 32-bit dependencies. We also added LD_LIBRARY_PATH_64 and LD_LIBRARY_PATH_32 as a means of specifying search paths that are specific to a class of objects. These class specific environment variables are used instead of any generic LD_LIBRARY_PATH setting.

Which leads me back to the recent email discussion. Seems a customer was setting both the _64 and _32 variables as part of their startup script, because both 64 and 32 bit processes could be spawned. However, one spawned process was acroread. Its LD_LIBRARY_PATH setting was being overridden by the _32 variable, and hence it failed to execute.

Sigh.

Is there a solution to this mess? I guess we could keep bashing LD_LIBRARY_PATH into submission some way, but why not get rid of the LD_LIBRARY_PATH requirement altogether? This can be done. Applications and dependencies can be built to include a runpath using ld(1), and the -R option. This path is used to search for the dependencies of the object in which the runpath is recorded.

If the dependencies are not in a constant location, use the $ORIGIN token as part of the pathname.

Is there a limitation to $ORIGIN use?

Yes, as directed by the security folks, expansion of this token is not allowed for secure applications., But then again, for secure applications, LD_LIBRARY_PATH components are ignored for non-secure directories anyway.

For a flexible mechanism of finding dependencies, use a runpath that includes the $ORIGIN token, and try not to create secure applications :-)

Join the discussion

Comments ( 6 )
  • Albert White Sunday, July 11, 2004
    I sometimes use LD_PRELOAD rather than LD_LIBRARY_PATH, which operates somewhat similarly to the LD_LIB_SUBSTITUTE mentioned by Chris. LD_PRELOAD=/home/usr/proj/mylibc.so.1 will cause mylibc.so.1 to be loaded and checked for the function and if found will not continue to search for the function. It all works fine until you run into a program that sets the environment pointer to null, but then none of these variables will work anyway!
  • benr Sunday, July 11, 2004
    Why not avoid the whole matter and rely on crle? Or is this to simply avoid root access? While there are still good cases in while LD env's are useful, it seems like 90% of the times that people use LD env's they should be using crle.
  • Rod Evans Thursday, July 22, 2004

    The read only data section is part of the text segment. When the memory image of the file is created, there is typically space between the text and data segments. But within the file image, the text and data segments are typically adjacent.
    Thus there is no space to put this new string.

    If we squeezed a new string between the text and data, the data location has changed, which would invalidate offsets and relocations that had already been established during the link-edit of the file.

    Plus, the runpath index from the <tt>.dynamic</tt> table is an index into the dynamic string table <tt>.dynstr</tt>. If we were create a runpath in some other section, and fabricate an index to it, its quite possible that some <tt>ELF</tt> tools will flag this index as invalid.

    And, you can't squeeze a new string at the end of the writable data segment either, as this is where the <tt>.bss</tt> has been established, and gets zeroed at runtime.

  • Seongbae Park Friday, July 23, 2004
    Well, if we introduce a new elf section (or use some other section that can be extended) and let the runtime linker check the section and get the rpath from there and override existing rpath, that would work. Another even more clunky workaround is to fix the compiler/linker to add a fixed size ( MAXPATH ?) empty rpath to executables if it was built without explicit rpath with $ORIGIN macro. Of course, this won't help the existing binaries, whereas the former approach would work, but that requires new linker.
    I think it's hopeless to wait for them to fix the way they build their program since lazy developers will be lazy no matter how hard we try to educate them. So I think we need some mechanism to address this.
  • Rod Evans Monday, July 26, 2004

    Yes, we've considered all these, but as you point out, they don't fix old objects. And if folks can rebuild their objects they should consider
    <tt>$ORIGIN</tt> route.

    I don't think developers are lazy, they just don't always grasp some of the fine points of delivering a product into an environment where it can be used in multiple ways. Those that know of <tt>$ORIGIN</tt>
    are using it. Linux implemented it too. The intent of this article was simply to continue spreading the word.

  • Nurfarahin Bte Saradi Tuesday, April 10, 2018
    Continue spreading the word
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha