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

On Thu, Mar 06, 2014 at 09:40:30AM +0000, David Chisnall wrote:
> On 6 Mar 2014, at 00:10, Eitan Adler <lists at> wrote:
> > This is confusing and leads to the same issues that the other
> > wait calls have.  IMHO it would be better to implement pdwait() and
> > deny waitpid().  This also leads to cleaner documentation: "the wait*
> > calls do not work on process descriptors".
> Except that there isn't a clear distinction.  Processes created with pdfork() have a pid that appears in the global PID namespace (visible to non-capsicum processes) and accessible via the pdgetpid() call.  Therefore, the distinction between a process created with pdfork() and one created with fork() is only visible to the process that spawned the child.
> Preventing wait*() from working on pids for processes that are created with pdfork() is going to cause massive pain for any application (e.g. debuggers, init systems, and so on) that want to wait for processes that are not their immediate children.  
> The wait*() calls work on a global namespace.  They are calls that are *only* useable by processes that are running with ambient authority.  They should not be restricted based on the way in which the PID was created, because this is not a globally visible property and would be a serious POLA violation.  

I fully agree with David. A process created with pdfork(2) has a PID, so
syscalls operating on PIDs (wait*(), kill(2), etc.) should continue to
work. Also note a special case when the PD_DAEMON flag is used for
pdfork(2) and the process can exists even if all process descriptors are

Pawel Jakub Dawidek             
FreeBSD committer               
Am I Evil? Yes, I Am!           

Attachment: pgptdRyBAt1WV.pgp
Description: PGP signature

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