From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13039 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Possible oversight in setvbuf() Date: Fri, 13 Jul 2018 22:03:27 -0400 Message-ID: <20180714020327.GF1392@brightrain.aerifal.cx> References: <20180713144052.GA13099@voyager> <20180713213110.GD1392@brightrain.aerifal.cx> <20180713220606.GE1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1531533743 15693 195.159.176.226 (14 Jul 2018 02:02:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Jul 2018 02:02:23 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13055-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 14 04:02:19 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fe9t5-0003zL-Kf for gllmg-musl@m.gmane.org; Sat, 14 Jul 2018 04:02:19 +0200 Original-Received: (qmail 24526 invoked by uid 550); 14 Jul 2018 02:04:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24311 invoked from network); 14 Jul 2018 02:03:40 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13039 Archived-At: On Fri, Jul 13, 2018 at 06:19:30PM -0400, Christopher Friedt wrote: > On Fri, Jul 13, 2018, 6:06 PM Rich Felker, 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