4 ms·

So, similar to pdfork in Capsicum and FreeBSD?

• JoshTriplett 11y ago
  Similar, and we specifically took pdfork into account by trying to make sure interface-compatible userspace wrappers for pdfork could exist using CLONE_FD. (For instance, we made poll() on a CLONE_FD file descriptor set POLLHUP in addition to POLLIN, since poll() on a pdfork file descriptor sets POLLHUP.) However, last I looked at pdfork, it didn't solve the problems we needed it to: 1) Most critically, processes created with pdfork still get picked up by standard waitpid/wait4 calls when they exit, which means you can't separate them from a global wait loop in the parent process. That makes it impossible to handle the child process from within a library without interfering with the parent process at all. (Similar to the problem that a process can only have a single process-wide SIGCHLD handler; those two problems together motivated the creation of CLONE_FD in the first place.) 2) It requires special calls like pdwait4 rather than just a simple read. 3) It defaults to sending SIGKILL when closing the fd, and with capsicum enabled it only allows that mode. 4) pdwait4 didn't actually exist in a functional form yet, so to work with current BSD you'd have to call pdgetpid and wait4 instead. (Which you can't do in Capsicum mode, or from a process other than the parent process.) This may have been fixed since the last time we looked at it, though. 5) pdfork only provides the semantics of fork, rather than the full semantics of clone. All that said, I'm a big fan of Capsicum and the way it rethinks core APIs and resources to function around file descriptor handles.