Date: Sat, 13 Sep 2014 12:04:52 +0400 From: Andrey Chernov <ache@freebsd.org> To: Peter Wemm <peter@wemm.org>, freebsd-current@freebsd.org Cc: Patrick Kelsey <kelsey@ieee.org>, George Neville-Neil <gnn@freebsd.org> Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient Message-ID: <5413FAA4.70406@freebsd.org> In-Reply-To: <4252906.DAHIEnKpIF@overcee.wemm.org> References: <CAD44qMWgWn_OZ1i0Jy2WTLY=YAai%2B6-_Bq24QN-AjD9iYJ2JOA@mail.gmail.com> <540FF706.2050400@freebsd.org> <CAD44qMV_AVYO2nwUJO27T8MYbacj2GgxectXtBuHU2qnWq_Ppw@mail.gmail.com> <4252906.DAHIEnKpIF@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ache@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5413FAA4.70406>