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_at_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/
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:52 UTC