From owner-freebsd-current@FreeBSD.ORG Wed Sep 17 20:45:26 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E0DFEA48; Wed, 17 Sep 2014 20:45:26 +0000 (UTC) Received: from smtp2.wemm.org (smtp2.wemm.org [192.203.228.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp2.wemm.org", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C20067D2; Wed, 17 Sep 2014 20:45:26 +0000 (UTC) Received: from overcee.wemm.org (canning.wemm.org [192.203.228.65]) by smtp2.wemm.org (Postfix) with ESMTP id 6029FE0C; Wed, 17 Sep 2014 13:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=m20140428; t=1410986726; bh=fqSHcHdrt5jVuyjlMB7AdQzAA+/MVJwo90D1aTwLmCQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mXwKuU9x1NoxQBQuNBMw9zF7zQcvV0gzQH8qGcNUXDD3FjBApNeRiiEOW8hWo2skx Dl99Z/gpqLvxwNVFsvZaXjPtuf0oc2tHj6LL7JWEaWmRNvWMJ+NaUe+CpDvjzIwKCq 6EF/0Mwf7xX3W1rIPKoV87FwM4mq2MP0bYeiZpsQ= From: Peter Wemm To: freebsd-current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient Date: Wed, 17 Sep 2014 13:45:25 -0700 Message-ID: <52259934.QGKubh7NGh@overcee.wemm.org> User-Agent: KMail/4.12.5 (FreeBSD/11.0-CURRENT; KDE/4.12.5; amd64; ; ) In-Reply-To: <20140916104236.GA21560@dft-labs.eu> References: <4252906.DAHIEnKpIF@overcee.wemm.org> <20140916104236.GA21560@dft-labs.eu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9799685.Ygpvd2xJnP"; micalg="pgp-sha1"; protocol="application/pgp-signature" Cc: Patrick Kelsey , George Neville-Neil , Mateusz Guzik X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 20:45:27 -0000 --nextPart9799685.Ygpvd2xJnP Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Tuesday, September 16, 2014 12:42:36 PM Mateusz Guzik wrote: > On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote: > > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > > > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov =20 wrote: > > > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > > > I don't think it is worth the trouble, as given the larger pa= ttern > > > > > of > > > > > libc routines requiring multiple capsicum rights, it seems on= e will > > > > > in > > > > > general have to have libc implementation knowledge when using= it in > > > > > concert with capsicum. For example, consider the limitfd() r= outine > > > > > in > > > > > kdump.c, which provides rights for the TIOCGETA ioctl to be u= sed on > > > > > stdout so the eventual call to isatty() via printf() will wor= k as > > > >=20 > > > > intended. > > > >=20 > > > > > I think the above kdump example is a good one for the subtle = issues > > > > > that > > > > > can arise when using capsicum with libc. That call to isatty= () is > > > > > via a > > > > > widely-used internal libc routine __smakebuf(). __smakebuf()= also > > > > > calls > > > > > __swhatbuf(), which in turn calls _fstat(), all to make sure = that > > > > > output > > > > > to a tty is line buffered by default. It would appear that p= rograms > > > > > that restrict rights on stdout without allowing CAP_IOCTL and= > > > > > CAP_FSTAT > > > > > could be disabling the normally default line buffering when s= tdout > > > > > is a > > > > > tty. kdump goes the distance, but dhclient does not (restric= ting > > > > > stdout > > > > > to CAP_WRITE only). > > > > >=20 > > > > > In any event, the patch attached to my first message is seemi= ng like > > > > > the > > > > > way to go. > > > >=20 > > > > Well, then commit it (if capsicum team agrees). > > >=20 > > > Will do - thanks for the feedback. > > >=20 > > > -Patrick > >=20 > > Is there any possibility that this is related to the problem we've > > recently > > hit in the freebsd.org cluster with this month's refresh? > >=20 > > After running for a while: > > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: valid= ator > > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: itera= tor > > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > >=20 > > Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracef= ully > > last time (65258) > > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: valid= ator > > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: itera= tor > > Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > >=20 > > Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracef= ully > > last time (28213) > > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: valid= ator > > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: itera= tor > > Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > >=20 > > I believe this jail was started from the boot process. If I restart= the > > jail by hand from a ssh session the problem goes away. > >=20 > > This is unbound from ports and I don't have any more details than t= his.=20 > > This is new this month. >=20 > Is this thingy multithreaded? >=20 > Currently there is a race in the kernel where fd is visible before > relevant capabilities are installed. This can result in an error like= > this one for weird processes. >=20 > I got a patch for this: > http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.ht= ml >=20 > but it got stalled on 'memory barrier' discussion. I'll try to ping > people to move it forward. >=20 > IIRC there was a report of unbound failing this way, apparently fixed= > with aforementioned patch. Yes, unbound is multi-threaded and your comment is the first potential=20= explanation that makes sense so far. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart9799685.Ygpvd2xJnP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUGfLmAAoJEDXWlwnsgJ4ENUIIAML+6cjn5sDZS/6pgu/Jfo/J c9TRcTPuBhOsG/XhsF2IklOt8NmwUYIMHm6NhzQEjTbdvzaAGlBB4EON+Hw+q0Wt FnhXArUIPhDKOhWIiLKW9Z/lC+qaJFzH1sbKs41demCeaNdtwTiIXZjkLMfeXn10 3UwHldzeWTRrt+P9oy7YIJl0sMUdwPdIgrkpysuf+e3X3YHeZEhZYb7UBHE9O0YT vAxvv+m5i5Zlz5S22JRd+q1hZYvfuHfFK6DNtHldKhtCgqdbY78AnOiEw83ZTZLa uKMqTdE9Zqliipkci8c3Rg/YjmsC6lIlmjMeJNI296R4myhddcja7nb3Q7aQWW0= =Q1vR -----END PGP SIGNATURE----- --nextPart9799685.Ygpvd2xJnP--