From owner-freebsd-current@FreeBSD.ORG Sat Sep 13 08:33:49 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80753444 for ; Sat, 13 Sep 2014 08:33:49 +0000 (UTC) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1785D3A for ; Sat, 13 Sep 2014 08:33:48 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id p9so2135396lbv.0 for ; Sat, 13 Sep 2014 01:33:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=7vUaOuWoWDeqaZJ343Z/6qUGWX60mSc9GrscKlCUVFk=; b=D27rwvi/8u9ndLAfDNe6croTQMRLNQFNi1TLTgzYFQ339KCwFAPonzs+9dWCEYfn+/ U6b9OVfCX9t9Qo7JXh3tvXlks6Q230Tr0x8HlrNrmnFYqMer2xDzPDqN1ckKGEqI6nwc Z08jqwhgD8hL6hdDugvWFjNhNpM3o96ZHDUisiehE6ev38/dUk/HDaEDXOQIdaxGApRW iUSSJOQXEPSiOt+ACI1IQnCso2Bmwu5ekrD3Q3zzdXHi0OYsE8kX22XcNpYU+q/vJhWj xL1Yi+rkJ0m6xHvGCRG+zrD/Y1OBvwkASl+2Iyi0M1+kBM3U5quzl6SABDxHoP9Xeu1G pspQ== X-Gm-Message-State: ALoCoQlDIBCcJWWlLj6nk2olGProwxlJ1aoeWva/Z0Ki2MGC2WLSfbDiC2DGNF7JBmhuWFHTrEIk X-Received: by 10.152.44.162 with SMTP id f2mr14265979lam.84.1410595503522; Sat, 13 Sep 2014 01:05:03 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id rl6sm1992315lac.17.2014.09.13.01.05.02 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Sep 2014 01:05:02 -0700 (PDT) Message-ID: <5413FAA4.70406@freebsd.org> Date: Sat, 13 Sep 2014 12:04:52 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Peter Wemm , freebsd-current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient References: <540FF706.2050400@freebsd.org> <4252906.DAHIEnKpIF@overcee.wemm.org> In-Reply-To: <4252906.DAHIEnKpIF@overcee.wemm.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv" Cc: Patrick Kelsey , George Neville-Neil 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: Sat, 13 Sep 2014 08:33:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: quoted-printable On 13.09.2014 8:29, 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 wro= te: >>> On 09.09.2014 21:53, Patrick Kelsey wrote: >>>> I don't think it is worth the trouble, as given the larger pattern o= f >>>> libc routines requiring multiple capsicum rights, it seems one will = in >>>> general have to have libc implementation knowledge when using it in >>>> concert with capsicum. For example, consider the limitfd() routine = in >>>> kdump.c, which provides rights for the TIOCGETA ioctl to be used on >>>> stdout so the eventual call to isatty() via printf() will work as >>> >>> intended. >>> >>>> 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 v= ia a >>>> widely-used internal libc routine __smakebuf(). __smakebuf() also c= alls >>>> __swhatbuf(), which in turn calls _fstat(), all to make sure that ou= tput >>>> to a tty is line buffered by default. It would appear that programs= >>>> that restrict rights on stdout without allowing CAP_IOCTL and CAP_FS= TAT >>>> could be disabling the normally default line buffering when stdout i= s a >>>> tty. kdump goes the distance, but dhclient does not (restricting st= dout >>>> to CAP_WRITE only). >>>> >>>> In any event, the patch attached to my first message is seeming like= the >>>> way to go. >>> >>> Well, then commit it (if capsicum team agrees). >> >> Will do - thanks for the feedback. >> >> -Patrick >=20 > Is there any possibility that this is related to the problem we've rece= ntly=20 > 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: validator= > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch retu= rned=20 > error -1, errno is Capabilities insufficient unbound itself does not use capsicum, just grep cap_, ldns too, so the problem can be somewhere else. --=20 http://ache.vniz.net/ --IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUE/qtAAoJEKUckv0MjfbKTpUIAI4tTHUILv8yi07rD6VJq1P1 aJ0rxMpQgtTvWSOCCwWJyV07zalHIhV46lXKUoMh95MLxHASVvb6ACNxHjRXG0sC cmZSGuKfow0lmVJF0t1Qu8KNZ+WOsMV9nN1tg9SlGpW6OovmiYkRZB6a+beAjOkH SxSlihslbnRyJYwlezzG2eJPRzXk36Drs8B7X2dIkWIgSqbO7tRQyeabacpTvsXm zc1ex3A033+G9AIgHu2Sjbi0IdfhT4yunIqfFQdUW3xKFVQH2qOjSgu6f1Y0wm2R kDgmaaWQ/zrrbYe4eziTGtDr7tQTA3l3cIW1gA1bO19K9ODYvS2KAiEt4sccT08= =UGo1 -----END PGP SIGNATURE----- --IJfM9vRiAnbPJtgxlfusjGfw2GaiiGURv--