Re: [PATCH] Link dynamic tests with newly built glibc

[Roland McGrath <roland at hack dot frob dot com>]

> > I am not at all sanguine about having a production dynamic linker pay
> > attention to a magic environment variable like GLIBC_SYSROOT.  I'd be more
> 
> I don't think such a variable is really any different in principle from 
> those such as LD_LIBRARY_PATH, GCONV_PATH and LOCPATH - but it certainly 
> simplifies the use of a glibc installation not installed directly into /, 
> as otherwise you have lots of variables to set (and some standard paths 
> glibc searches have no corresponding environment variable at all), and 
> there are uses of that beyond just running tests.

I understand your point.  That doesn't make me any less circumspect about
adding new environment variables that can drastically change runtime
behavior, especially in ways that are clearly relevant to security.

Yes, we have various kinds of environment scrubbing and so forth.
But it's also the case that the set of environment variables that
can influence libc/rtld is well-known and rightly considered
security-relevant outside just the code we control.

Note I didn't say we'll never do it or something like it.  I said
"not sanguine", and "circumspect".  That means it's not something we
would do lightly, and not something we can just try out casually and
worry about all the ramifications later.  We need to give it very
careful considerations and contemplate all the options and their
relative merits and drawbacks.

> > inclined to link an almost-normal ld.so specifically for testing.  It would
> 
> One use case for testing I'd like supported is testing a previously built 
> glibc, not necessarily installed in /, without needing the build tree in 
> which it was built.  

Agreed.

> Special variants of ld.so or libc.so that are used in 
> testing but not installed are bad for that.  

There is also the possibility of installing such a variant (under a
different name) for just such purposes.  (Yes, I know that also has
many issues.)

> (For things such as linkobj/libc.so, used in sunrpc tests, maybe there
> should be an option to install them somewhere for later use in testing.

That's only used to build the tests, not to run them.  I think you
are actually talking about two use cases, and perhaps conflating
them unintentionally (or perhaps I just can't tell for sure which
one of them you had in mind).  One is building test binaries once
(when arbitrary amounts of detail from the libc build are readily
available) and running them later in other circumstances.  The other
is building tests from source in a different environment.  The
notion of using linkobj/libc.so outside the libc build only applies
to the latter.

Both cases are worthwhile ones to be concerned with, but we should
be precise about what case requires what work.

> For tests such as tst-xmmymm.sh or check-local-headers.sh that are
> fundamentally based around examining the build tree rather than running
> things built with the installed library, maybe they should actually be
> part of the build process rather than part of a testsuite run.)

I agree these are in a different category than other tests and we
should treat them differently.  That's a separate issue from whether
it's 'make' or 'make check' that runs tests of a particular category.


Thanks,
Roland