On Thu, Mar 06, 2014 at 09:40:30AM +0000, David Chisnall wrote:I fully agree with David. A process created with pdfork(2) has a PID, so
> On 6 Mar 2014, at 00:10, Eitan Adler <lists at eitanadler.com> 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.
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 http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com