Date: Fri, 28 Mar 2014 21:07:08 +0000 From: u-igbb@...ey.se To: musl@...ts.openwall.com Subject: Re: be able to break inheritance of LD_LIBRARY_PATH 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
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.