Re: be able to break inheritance of LD_LIBRARY_PATH

[u-igbb@aetey.se]

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