From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4728 Path: news.gmane.org!not-for-mail From: u-igbb@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: be able to break inheritance of LD_LIBRARY_PATH Date: Fri, 28 Mar 2014 14:00:36 +0000 Message-ID: <20140328140036.GC8221@example.net> References: <20140328104208.GZ8221@example.net> <20140328131718.GH27448@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1396015261 20942 80.91.229.3 (28 Mar 2014 14:01:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Mar 2014 14:01:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4732-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 28 15:01:11 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WTXLI-0006JN-Ro for gllmg-musl@plane.gmane.org; Fri, 28 Mar 2014 15:01:08 +0100 Original-Received: (qmail 9619 invoked by uid 550); 28 Mar 2014 14:01:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9610 invoked from network); 28 Mar 2014 14:01:08 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe05.swip.net; client-ip=178.254.39.32; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140328131718.GH27448@port70.net> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:4728 Archived-At: On Fri, Mar 28, 2014 at 02:17:19PM +0100, Szabolcs Nagy wrote: > * u-igbb@aetey.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