LD_LIBRARY_PATH - just say no

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 :-)

Saturday, July 10, 2004 | Technologies | Read More

Hello there

So, blogs seem popular, and a couple of folks have suggested I start one, so here it is. I've been at Sun for 15 years, most of that time developing and maintaining the linker-editors, various related tools, documentation, and building lots of software. The link-editors start with ld(1), which takes various input from the compilers, and typically spits out a dynamic executable or share object. Then there's ld.so.1(1), the runtime linker, which takes a dynamic executable and...

Wednesday, July 7, 2004 | Technologies | Read More

Solaris x86 FAQ

Just testing this weblog/wiki software. I keep a FAQ on Solaris x86, which I started before I started at Sun. My work at Sun is not on Solaris x86, but software for the high-end UltraSparc systems, Starcat (Sun Fire 15K and friends). Currently, I'm working on Fault Management Software for Starcat. Technorati Tag:

Monday, June 7, 2004 | Technologies | Read More

Toorcon 2003 Information Security Conference

Unofficial Report on Toorcon 2003 Information Security Conference align="middle" border="0" /> San Diego, CA, http://www.toorcon.org/ Dan Anderson, September 2003 These notes are on a conference I attended last weekend (on my dime, or actually 500 dimes and tax-deductible). This is an annual conference for people interested in computer security. This includes the whole range of hackers, computer hobbyists, professionals, security consultants, press,law enforcement,...

Monday, September 29, 2003 | Technologies | Read More