Re: Fixing the glibc runtime linker

[Rich Felker <dalias () libc org>]

On Fri, Feb 20, 2015 at 08:44:28AM -0800, Paul Pluzhnikov wrote:
> On Fri, Feb 20, 2015 at 1:22 AM,  <Casper.Dik () oracle com> wrote:
> > > FWIW, relative RPATHs are quite fundamental to our test execution
> > > environment, and any patch that unconditionally ignores them would
> > > have to be reverted in our tree.
>
> It turns out I was mistaken: we don't use relative RPATHs after all.
>
> > But wouldn't that make the libraries and executables less reliable?
>
> Our testing infrastructure is described in some detail here:
> http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html
>
> The essential problem is that the paths to all the libraries in the cloud
> are effectively unpredictable. They are however predictable relative to
> $ORIGIN, which is what we actually use [1].

${ORIGIN}-based RPATH is not subject to the same security issues as
cwd-relative RPATH. There are some issues to consider with suids
(malicious hardlinks, for example) but I believe these can all be
mitigated by having the whole device non-writable except by root or
enabling hardlink restrictions in the kernel.

> > They can pick up random libraries or cause some delays when one of the
> > relative paths points to a NFS mounted directory.
>
> We only build tests that way, not final binaries. Random libraries and
> NFS are not a concern for us, because the 'in the cloud' environment is
> tightly controlled -- we know exactly what files the test will see at
> runtime (relative to $ORIGIN).
>
> > Any reason you can't change to using LD_LIBRARY_PATH for testing?
>
> We used to use LD_LIBRARY_PATH, but it has several problems. Consider a
> Python or Java program that needs to load some C++ shared library, and
> also wants to fork off a separate C++ executable. Consider further that
> the python may be built for ix86, while the C++ executable may be built
> for x86_64.
>
> What should the LD_LIBRARY_PATH look like? Should it leak from python into
> C++ executable? It's complicated :-)

For exactly this reason -- that it's inherited -- LD_LIBRARY_PATH
really should not be used, or at least its use should be limited to
building and testing, not actual deployment. RPATH is a much more
appropriate tool.

Rich