[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180714020327.GF1392@brightrain.aerifal.cx>
Date: Fri, 13 Jul 2018 22:03:27 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Possible oversight in setvbuf()
On Fri, Jul 13, 2018 at 06:19:30PM -0400, Christopher Friedt wrote:
> On Fri, Jul 13, 2018, 6:06 PM Rich Felker, <dalias@...c.org> wrote:
>
> > On Fri, Jul 13, 2018 at 05:46:54PM -0400, Christopher Friedt wrote:
> > > A good process for adding new features is to add tests with them. Even if
> > > there is only a test for expected behaviour, at least it will catch one
> > > possible regression.
> >
> > Yes, I should really do that more. Sometimes it's not obvious what
> > should be tested though. In the case of setvbuf, the intended behavior
> > is in some sense untestable (the previous implementation not using the
> > caller-provided buffer was valid); in hindsight the obvious important
> > thing to test is that it doesn't result in writes outside the buffer.
> >
>
> If you need more than that basic test.c program that I provided before for
> addrconfig, i'd be happy to add some more test cases.
The hard thing about testing that functionality is that it's dependent
on environmental factors (network interface configuration). The same
problem also applies to the rest of the resolver functionality, where
you'd want to be able to hook it up to a known, and possibly
malicious, nameserver that's part of the test harness.
There are two "obvious" choices for how to achieve this:
1. Using Linux namespaces (and assuming user namespace functionality
is available to access them, which requires either appropriate
configuration or root) so that control over the filesystem and
network interfaces is available. Or,
2. Implementing a tracer (perhaps just seccomp) process that catches
and rewrites the syscall results to simulate the conditions we want
to test.
Neither is particularly portable outside of Linux (note that libc-test
is OS- and libc-agnostic). Option 1 is cleaner and simpler and more
flexible, but won't work on all systems (and especially not on more
hardened ones). I'm not sure if Szabolcs Nagy (libc-test maintainer)
likes either idea.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
