On 2021-May-06 19:07:23 -0400, monochrome <monochr...@twcny.rr.com> wrote: ... >On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote: ... >> server% tail /COPYRIGHT <&- >> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file >> /usr/src/lib/libcasper/libcasper/service.c, line 394. >> tail: unable to init casper: Socket is not connected
>I get a different error on a 13.0-RELEASE machine I converted from 12 to >current about a year ago (bash and sh): > >$ tail /COPYRIGHT <&- >tail: can't limit stdio rights: Bad file descriptor I've done some more testing across a number of systems and narrowed the difference in behaviour down to the presence of the CAPABILITIES option in the kernel (it looks like I never added it to my kernel config on that system): If CAPABILITIES is present then the cap_rights_limit(2) call for the closed FD fails, generating the "can't limit stdio rights" error. (Whether this behaviour is reasonable is a different issue - it was introduced in r348708, based on https://reviews.freebsd.org/D20393 and the issue of closed file descriptors doesn't seem to have been considered). If CAPABILITIES is not present then the cap_rights_limit() failure is (correctly) ignored but the subsequent fileargs_init(3) call gets upset at opening a FD <= 2. This behaviour seems wrong - if CAPABILITIES aren't present in the kernel then the userland behaviour should be the same as if WITHOUT_CASPER is specified. IMO, this is a bug in fileargs_init(3). -- Peter Jeremy
signature.asc
Description: PGP signature
