[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140328140036.GC8221@example.net>
Date: Fri, 28 Mar 2014 14:00:36 +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 02:17:19PM +0100, Szabolcs Nagy wrote:
> * u-igbb@...ey.se <u-igbb@...ey.se> [2014-03-28 10:42:08 +0000]:
> > For our software setup it is crucial (quite useful otherwise in general)
> > to be able to specify the location of the dynamic libraries per binary/run
> > _without_ the unconditional inheritance imposed by LD_LIBRARY_PATH.
>
> why do you use LD_LIBRARY_PATH then?
I "do not". I am using the --library-path argument to the dynamic loader.
(Unless LD_LIBRARY_PATH is forced upon myself by someone else;
then I need protection from its potentially detrimental side effects)
Otherwise relying on LD_LIBRARY_PATH would be the only option.
(A hardwired library reference makes it impossible to replace
libraries otherwise than "in place", which is bad for many reasons)
> > A very nice solution would be the ability to explicitely run a standalone
> > dynamic loader, as implemented in both glibc and uclibc. We are heavily
> > relying on this functionality.
> if you mean you can run '/lib/ld-linux.so.2 binary' then musl can do the same
Thanks for pointing me in the right direction.
I was thinking of a "cheap and dirty workaround" while the most
appropriate is of course to add the missing argument parsing.
> if you dont control the environment you will have other issues
> (eg with LD_PRELOAD)
>
> if you do control the env then just unset LD_LIBRARY_PATH
This is kind of what I thought of doing, in the loader.
By the way, when you say this - LD_PRELOAD should be actually usable
in a non-inheritable way too. It brings otherwise the same problems
as LD_LIBRARY_PATH. It could deserve its own loader argument I guess,
like --preload.
> (there ar no "different versions of the loader" in musl)
Yes this is why I thought that a LD_LIBRARY_PATH removal would
be enough. Of course it is much better to do this properly, by
extending the behaviour of the loader when it is being used standalone.
This would cost just a few bytes I guess. I will look into proposing a patch.
> in case you do a lot of lib path hacks note that the path lookup is
> different in glibc than in musl:
Thanks, good to keep in mind - otherwise not crucial given that I
do my best to avoid rpath and the fallbacks.
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.
