Home page logo
/

bugtraq logo Bugtraq mailing list archives

The LD_* vars (was Re: LD_ hole)
From: jmason () iona ie (Justin Mason)
Date: Thu, 16 Dec 1993 12:59:43 +0000


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)



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault