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
[-- Attachment #1 --] 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> wrote: >>> On 09.09.2014 21:53, Patrick Kelsey wrote: >>>> I don't think it is worth the trouble, as given the larger pattern of >>>> 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 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 programs >>>> that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT >>>> could be disabling the normally default line buffering when stdout is a >>>> tty. kdump goes the distance, but dhclient does not (restricting stdout >>>> 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 > > 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? > > 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 returned > error -1, errno is Capabilities insufficient unbound itself does not use capsicum, just grep cap_, ldns too, so the problem can be somewhere else. -- http://ache.vniz.net/ [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUE/qtAAoJEKUckv0MjfbKTpUIAI4tTHUILv8yi07rD6VJq1P1 aJ0rxMpQgtTvWSOCCwWJyV07zalHIhV46lXKUoMh95MLxHASVvb6ACNxHjRXG0sC cmZSGuKfow0lmVJF0t1Qu8KNZ+WOsMV9nN1tg9SlGpW6OovmiYkRZB6a+beAjOkH SxSlihslbnRyJYwlezzG2eJPRzXk36Drs8B7X2dIkWIgSqbO7tRQyeabacpTvsXm zc1ex3A033+G9AIgHu2Sjbi0IdfhT4yunIqfFQdUW3xKFVQH2qOjSgu6f1Y0wm2R kDgmaaWQ/zrrbYe4eziTGtDr7tQTA3l3cIW1gA1bO19K9ODYvS2KAiEt4sccT08= =UGo1 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5413FAA4.70406>