The LD_* vars (was Re: LD_ hole)

[jmason () iona ie (Justin Mason)]

In your message of Wed, 15 Dec 1993 13:18:14 MST, you say:

> > c) delete any environment varable that begins with LD_
>  Most people have said this for obvious reasons, but the ld manpage says
> that will not search anything (for suid binaries) other than the trusted
> paths for dynamically linked libraries even if LD_LIBRARY_PATH is set. Is
> this statement false? Is there a way around it? Is LD_PRELOAD_PATH documented
> anywhere?:-)

Okay, here's all the under-documented stuff about LD_* variables, mostly
from my own and other people's hacks on SunOS 4.1.2:

> 11:55:16 - 54 #...; strings /lib/ld.so | grep LD_
> LD_LIBRARY_PATH
> LD_TRACE_LOADED_OBJECTS
> LD_PROFILE
> LD_PRELOAD
> LD_SYMBOLS_PUBLIC

LD_LIBRARY_PATH: you know what this is.

LD_PRELOAD: the name of file(s) to include, a la LD_LIB_PATH libraries.
        It's a colon-separated list. On Solaris 2.x, this list is
        space-separated (Linkers And Libraries Manual, p.21).

LD_TRACE_LOADED_OBJECTS: set this, and it shows the expected shared libs
        every time you run a command. Not very insecure, but now you know
        how ldd(8) works! ;)

LD_PROFILE: I have no idea -- Caspar H. Dik might (he knows these things).

LD_SYMBOLS_PUBLIC: prints the path to the runtime linker, ld.so(8), in use.
        It only seems to have an effect when you use ldd(8).

There's more on Solaris 2.x: from the Linkers And Libraries Manual:

LD_BIND_NOW: set this, and ld.so will check for unresolved function references
at run-time. Ordinarily, it delays resolving them until the function is
invoked; see p.22.

LD_BINDINGS: "ld.so displays the actual symbol resolution", p.27.

There's also LD_SIGNAL, LD__OUTPUT (may just be LD_OUTPUT), LD_BIND_NOT (!),
LD_WARN.  God only knows what they do. Then there's the regulars:
LD_LIBRARY_PATH, LD_TRACE_LOADED_OBJECTS, LD_PROFILE and LD_PRELOAD.

Anyway, that's all I know -- one of the shared-lib gurus (Caspar H. Dik or
Oleg Kibirev) could probably fill in the rest.

--
Justin Mason (Iona Technologies' unix caretaker, fixer-upper and disk-filler)
email addr: <jmason () iona ie>            http://www.iona.ie/hyplan/jmason.html
"I was an infinitely hot and    -><-    (disclaimer:   these are my opinions,
dense dot."  --  Mark Leyner    -><-    usually not those  of  my  employers)