[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140328210256.GG8221@example.net>
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.
