From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4736 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: be able to break inheritance of LD_LIBRARY_PATH Date: Fri, 28 Mar 2014 15:46:38 -0400 Message-ID: <20140328194638.GO26358@brightrain.aerifal.cx> References: <20140328104208.GZ8221@example.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1396036004 31551 80.91.229.3 (28 Mar 2014 19:46:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Mar 2014 19:46:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4740-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 28 20:46:54 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 1WTcjr-0006W8-Tp for gllmg-musl@plane.gmane.org; Fri, 28 Mar 2014 20:46:52 +0100 Original-Received: (qmail 18109 invoked by uid 550); 28 Mar 2014 19:46:51 -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 18101 invoked from network); 28 Mar 2014 19:46:51 -0000 Content-Disposition: inline In-Reply-To: <20140328104208.GZ8221@example.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4736 Archived-At: On Fri, Mar 28, 2014 at 10:42:08AM +0000, u-igbb@aetey.se wrote: > Hello, > > I was aware of musl for some time and now consider deploying it as > a default library for new software builds, due to its very appealing > virtues. > > Yet there is a small but important issue. > > 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 aren't you using RPATH, possibly with a $ORIGIN base? This is a lot cleaner/saner than environment variables or invoking the dynamic linker explicitly with arguments. > 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. As others have said, this is already possible, and it's already setup to be able to handle option arguments before the command (if you're not sure the command name won't begin with a "-", you're supposed to put "--" before the command). So it's just a matter of adding the options. I haven't checked your patch yet, but the big things to consider are: - not breaking the current handling of "--" - whether --library-path and --preload should override/replace the values obtained from the environment or supplement them, and if the latter, whether they should have higher or lower priority > I do not know how hard it would be to teach the musl loader > to be runnable standalone and which corner cases this might create. > > 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. > > Compared to a standalone loader this lacks the ability to run > a binary with a different version of the loader/musl but at least > makes it straightforward and safe to freely specify where to find other > libraries. > > A naïve implementation might look as follows: > ... > + else if (!memcmp(argv[i], "FORGET_LD_LIBRARY_PATH=", 23)) > + forget_ld_library_path = 1; Adding new environment variables that are processed by libc outside of those specified by the standard and/or overwhelming real-world practice is not acceptable. If nothing else, this would be a security bug because there's no way applications can know they would need to unset this variable to keep it from taking effect. > auxv = (void *)(argv+i+1); > > + /* one _may_ wish to break the inheritance of LD_LIBRARY_PATH, > + * the hack below only works if the corresponding memory is writable > + * -- rl */ > + if (forget_ld_library_path) > + for (i=argc+1; argv[i]; i++) > + if (!memcmp(argv[i], "LD_LIBRARY_PATH=", 16) || > + !memcmp(argv[i], "FORGET_LD_LIBRARY_PATH=", 23)) > + argv[i][0] = 'X'; As written this possibly corrupts the environment (e.g. leading to TWO definitions of XD_LIBRARY_PATH in the environment). In any case this is the wrong approach. If you _really_ want to remove these vars once they're processed, you can use the LD_PRELOAD approach that calls unsetenv on them, but I think that's one of the worst solutions to the problem you're trying to solve (and RPATH/$ORIGIN is the best solution). Rich