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




On Fri, Mar 7, 2014 at 9:24 AM, Pawel Jakub Dawidek <pjd at freebsd.org> wrote:
On Thu, Mar 06, 2014 at 09:40:30AM +0000, David Chisnall wrote:
> 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.

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
closed.

Hmm, I think there's a possible awkward interaction with PD_DAEMON processes.  If a PD_DAEMON process gets reparented to init, and subsequently terminates, how does init reap it, given that pdfork()ed processes are invisible to waitpid(-1,...)?

Maybe make a PD_DAEMON process visible to (and reapable by) waitpid(-1,. ...) when the last process descriptor for it is closed?

More generally, I've started building a table with my current guesses for process descriptor behaviours -- feedback/discussion welcome:
  https://googledrive.com/host/0B9ALhQOmxxuGc1M5SlBMdE0wZG8/procdesc.html


 
--
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://mobter.com



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