[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140328214844.GS26358@brightrain.aerifal.cx>
Date: Fri, 28 Mar 2014 17:48:44 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: be able to break inheritance of LD_LIBRARY_PATH
On Fri, Mar 28, 2014 at 09:07:08PM +0000, u-igbb@...ey.se wrote:
> 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.
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.
> > - 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).
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 "-".
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 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. :-)
Rich
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.
