From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4739 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: Sat, 29 Mar 2014 07:25:49 +0000 Message-ID: <20140329072549.GH8221@example.net> References: <20140328104208.GZ8221@example.net> <20140328194638.GO26358@brightrain.aerifal.cx> <20140328210256.GG8221@example.net> <20140328214844.GS26358@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 1396077999 787 80.91.229.3 (29 Mar 2014 07:26:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2014 07:26:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4743-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 29 08:26:49 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 1WTnfE-0006Rd-Sz for gllmg-musl@plane.gmane.org; Sat, 29 Mar 2014 08:26:48 +0100 Original-Received: (qmail 28527 invoked by uid 550); 29 Mar 2014 07:26:46 -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 28519 invoked from network); 29 Mar 2014 07:26:46 -0000 X-T2-Spam-Status: No, hits=0.0 required=5.0 Received-SPF: none receiver=mailfe04.swip.net; client-ip=77.247.181.164; envelope-from=u-igbb@aetey.se Content-Disposition: inline In-Reply-To: <20140328214844.GS26358@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:4739 Archived-At: Hello Rich, On Fri, Mar 28, 2014 at 05:48:44PM -0400, Rich Felker wrote: > > Any hardcoded references make it impossible to update libraries in other > > way than "substituting in place" which affects all binaries containing > > the hardcoded reference. > > This is exactly the problem $ORIGIN exists to solve. Used in RPATH, > '$ORIGIN' or '${ORIGIN}' expands to the directory component of the > pathname of the executable or library the RPATH tag resides in. So you > can use things like RPATH=$ORIGIN/../lib or RPATH=$ORIGIN or similar. Unfortunately it does not help as everybody running the binary will pick up the same library/ies. I am supporting large and multiple groups of users running the same binary instances with potentially different libraries and vice versa. $ORIGIN helps if you are willing to copy the binary to somewhere else (and make corresponding copies or symlinks of the necessary libraries). This is possible but from my perspective quite impractical. Generally speaking, the approach of looking for resources relative to the binary's location is both insufficient and error-prone - it can (and does in practice) accidentally hit resources not meant to. With other words, you can not choose a place for a binary without "looking around" depending on what is designated inside it as its "nearby area of interest". Instead, I am using a straightforward framework where a tiny wrapper makes a freely configurable point-of-run for a binary and a set of library instances, wherever they happen to be located. This way I do not have any artificial constraints on the relative or absolute placement of the binaries and the libraries. > > 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). > > I'm definitely fine with adding --library-path. The intent was always > to add options compatible with or at least similar to those used by > other dynamic loaders; that's why I added the "--" handling early on > so that adding options would not be a feature regression (breaking the > ability to run programs whose names start with "-". Yes it looked like a preparation step. Appreciated. > As for --preload, I don't have any real objection but we should at > least stop a bit to consider adding nonstandard options that don't > have precedent in other implementations. Once we've added something > it's not really appropriate to remove it later. So I'd like to do just > --library-path for now if it will solve your problem and keep > --preload as a future idea. I would like to be able to specify preload per binary, not per process tree as LD_PRELOAD does. In the same way as LD_LIBRARY_PATH, LD_PRELOAD is dangerous on any "non-monolithic" system (i.e. when different application use different libraries). Even on a homogenous system a certain preload can be necessary for one application and totally unacceptable for another one in a child process. On certain hardware I used to use v4l1compat preload. Then when an application starts a child process using different libraries I remember occasions of getting error messages about preload failing. (I am routinely using in production a mix of applications linked to several different versions of glibc, uclibc and now musl). This was a mere annoyance but potentially could lead to harm. > > I hope you are more positive to the latter patch (which I consider > > being of acceptable quality). > > Yes, at first glance it looked right but I want to review it a bit > more. The comment about suid isn't needed; making the dynamic loader > suid is about the only thing stupider than making a shell suid. :-) :) Sure. Rune