From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4737 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 21:07:08 +0000 Message-ID: <20140328210256.GG8221@example.net> References: <20140328104208.GZ8221@example.net> <20140328194638.GO26358@brightrain.aerifal.cx> 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 1396040853 24791 80.91.229.3 (28 Mar 2014 21:07:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Mar 2014 21:07:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4741-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 28 22:07:41 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 1WTe04-0007CE-Tr for gllmg-musl@plane.gmane.org; Fri, 28 Mar 2014 22:07:41 +0100 Original-Received: (qmail 26427 invoked by uid 550); 28 Mar 2014 21:07:38 -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 26419 invoked from network); 28 Mar 2014 21:07:38 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe08.swip.net; client-ip=93.189.40.230; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140328194638.GO26358@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:4737 Archived-At: Hello Rich, Thanks for your answer. On Fri, Mar 28, 2014 at 03:46:38PM -0400, Rich Felker wrote: > 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. Any hardcoded references make it impossible to update libraries in other way than "substituting in place" which affects all binaries containing the hardcoded reference. It is important to be able to run a certain binary with a certain library without rewriting/replacing either the former or the latter (both can be needed and used by other parties who potentially do not expect/agree to any change!). > > 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 Sure I am aware of these issues. As much as I can tell I followed the behaviour of both glibc and uclibc (ignoring LD_LIBRARY_PATH when --library-path is present). (--preload is not present in those libraries but I feel it should behave the same way as --library-path). > Adding new environment variables that are processed by libc outside of ... > As written this possibly corrupts the environment (e.g. leading to TWO Sorry for presenting such an ugly example code. The purpose was merely to explain what I had in mind (which also was wrong per se as I didn't notice the possibility of adding the loader arguments). I hope you are more positive to the latter patch (which I consider being of acceptable quality). > problem you're trying to solve (and RPATH/$ORIGIN is the best > solution). We are certainly thinking about different goals. Hardcoded references (and even references read from files like /etc/something if the path to the file is hardcoded into the binary to be run) make it impossible to perform safe/limited (i.e. with a constrained impact on the multiple resource consumers) changes in the bindings between binaries and libraries. In this context RPATH is hardly a suitable tool, even if combined with $ORIGIN. Regards, Rune