Re: RFC: Test hook for nss_files testing

["Carlos O'Donell" <carlos at redhat dot com>]

On 12/10/2015 09:42 AM, Florian Weimer wrote:
> On 12/07/2015 09:50 PM, Carlos O'Donell wrote:
> 
>> What I'm asking is: Have you given thought to the security implications?
>>
>> Your answer is: Yes. A function is the best we can do.
>>
>> Did I understand that right?
>>
>> Can we harden this global table in any way?
> 
> To be honest, I'm confused by this request.  We do not usually take such
> issues into account when making changes to the library.
> 
> I think a function is indeed the best way, yes.

Perfect. No further questions.

>> I'm not against the new function, I'm against the test program having to use it
>> in a special way that makes it not behave like a regular application.
> 
> I see, and to some extend, I share that concern.

Good.

>>>> A more appealing alternative would be to run the test under a systemtap
>>>> script which did all the work of updating the paths to the databases
>>>> without the hook changes.
>>>
>>> I think this would be far more brittle and difficult to implement
>>> because the existing path names are just string literals.  Run-time
>>> patching also means that it's not really what we ship.  At that point,
>>> we may be better off with something like cwrap, or an xtest with chroot.
>>
>> I like both of those options better.
>>
>> If we are going to add hooks for testing like you propose it's going
>> to be because we absolutely need the hooks and there is no other way
>> to get at the information in question. It must be a last resort that
>> we add hooks like this since they incur maintenance burden forever.
>>
>> I think xtest+chroot is really the ideal solution here and would help
>> further containerized testing.
> 
> I'm not so sure.  Setting up the chroot in a realistic way is quite
> difficult.  You need to populat /dev and /dev/pts in some way, and
> arrange for the necessary GCC  and platform bits being present, whatever
> they are. âmake installâ may not actually produce a tree layout that is
> used by any downstream distribution.  And so on.  The list of issues is
> quite long.

In which regard do you think this is not ideal?

Should we rely on distro images?

Let the user choose which images to use for their target?

At the end of the day glibc has to test it's own functionality on what it
considers to be a normalized system root. When the distributions file bugs
we can compare their configuration to what we used in testing.

I don't think it matters that our `make install` is never used by downstream,
but it has to represent a reality that we are willing to support as glibc
developers.

Relying on downstream to test our work has very high latency and can result
in a lot of lost productivity. We really need to know immediately if a
change broke something.

Lastly, we may have to rely on some basic building blocks for doing this kind
of testing. Without those building blocks we mark the test UNSUPPORTED.
It is entirely plausible that at the start the test only works on x86_64,
requires docker, and runs slim Fedora container for testing. Other targets
need to fill in the technology pieces that would allow them to launch a
target system that can be configured for testing and which can be thrown
away or broken if the test fails.

Note: As a target test it will require quite a bit of resources on the target
      to run, including root, so it should continue to be xcheck.

> I think we could package such tests that they rewrite an existing chroot
> (or live VM image) and then do the testing they need.  But these tests
> still would not run as part of the build process.

That is one solution and was discussed at GNU Cauldron, we would create
a "libc-tests" project that is an add-on to glibc (using the add-on mechanism)
which would allow you to add-on additional tests that are more complex.

> I'll keep my patch around for local nss_files testing, but it seems that
> we don't want it yet in glibc proper.

I just don't think it's the right solution.

Cheers,
Carlos.