Re: [capsicum] wait() and pdfork()

On Wed, Mar 05, 2014 at 03:19:27PM +0000, David Drysdale wrote:
> On Wed, Mar 5, 2014 at 3:11 PM, Robert N. M. Watson <
> robert.watson at> wrote:

> > On 5 Mar 2014, at 14:05, Ben Laurie <benl at> wrote:

> > > David informs me that wait() does not behave as I expected with
> > > pdfork()ed children - I thought it should not reap them - so that
> > > pdfork()ed children can be invisible to s/w that includes a library
> > > that uses pdfork().

> > > Did I not understand something?

> > The intent was always that processes with process descriptors would not be
> > exposed to wait(2). That expectation doesn't preclude bugs in the
> > implementation. In the past, the implementation has worked well -- but it
> > sounds like there's a lack of a regression test. Snagging your tests and
> > putting them in the FreeBSD Project's budding Jenkins setup would be
> > excellent. :-)

Originally, processes with process descriptors would be visible via
SIGCHLD and wait calls in the normal way. Later, SIGCHLD was disabled
for them. I think it is appropriate to exclude them from waitpid(-1,
...) as well.

> I'll add a test case for this.  On a specific detail -- what do we expect
> to happen for waitpid(pdforked_child_pid,...) ?  This
> works<>at
> the moment, but I could be persuaded either way as to whether it
> should or not.

Right now, waitpid(pdforked_child_pid, ...) is the only way to detect
WIFSTOPPED/WIFCONTINUED and to obtain status and rusage information,
since pdwait is not implemented. So I suppose it will need to be

I'm not sure about the variants of waitpid that match all child
processes in a particular process group. I don't think they are commonly

> More generally, are there any examples of pdfork() usage in practice?  I
> had a quick look for sandboxed things using it and didn't immediately find
> any...

In the FreeBSD source tree, sbin/casperd and usr.sbin/rwhod use it. The
former also passes the process descriptor around using libnv.

Jilles Tjoelker

This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.