[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140328125143.GA8221@example.net>
Date: Fri, 28 Mar 2014 12:52:48 +0000
From: u-igbb@...ey.se
To: musl@...ts.openwall.com
Subject: Re: be able to break inheritance of LD_LIBRARY_PATH
On Fri, Mar 28, 2014 at 08:18:28PM +0800, orc wrote:
> >As a simpler approach I might suggest simply being able to drop
> >LD_LIBRARY_PATH as soon as it has been read. An extra environment
> >variable as a flag would do.
> Such change should be maintained locally by you probably.
It is what I'd very much like to avoid.
Local patches need to be maintained and make it painful to upgrade. The
functionality which I ask for is otherwise quite general and useful
(otherwise neither glibc nor uclibc would bother implementing it).
> While LD_PRELOAD/LD_LIBRARY_PATH environment variables are "standard"
> enough (widely known), introduction of extra variables that control
> various aspects of dynamic linker internals is becoming a pain, especially
Sure. I would prefer standalone execution. LD_LIBRARY_PATH is pretty much
broken by design anyway.
> maintain such a local change that introduces LD_NORPATH (disables reading
> DT_RPATHs from executable, and forces it for all setuids).
Yes, rpath is bad. My "locally patched" uclibc dynamic loader ignores it
unconditionally, as a precaution. Even though the decision to use rpath
(or not) should be on the one who compiles, it is virtually impossible
to cope with endless variations of build tools which either hardcode
rpath presence or even lie about "not using" rpath.
Regards,
Rune
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
