This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Test hook for nss_files testing


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.

> 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.

>>> 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.

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.

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

Florian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]