3 ms·

> As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. oooh. I'd be re

by i336_ 11y ago

> As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. oooh. I'd be really interested to learn about this... what exactly are you doing? (What can you do?!)

JoshTriplett 11y ago
Identifying processes with file descriptors instead of PIDs, initially by adding a new flag to clone, CLONE_FD, that gives you back a file descriptor for the new process. The descriptor becomes readable when the process exits, so you can manage a child process and get its status without SIGCHLD. That allows a library to manage child processes without messing with the signal handlers of the parent process using the library. Since the file descriptor holds a reference to the kernel data structure for a process (task_struct), that makes it race-free, unlike a PID (for anyone other than the parent process), and thus unlike a path within /proc (which uses the PID). So after getting CLONE_FD in, and adding ways to use a file descriptor in place of a PID in other syscalls, I'd like to add ways to use that process file descriptor to get back information about the process instead of using /proc (such as via ioctls). While there's sadly no video available, I gave a presentation at Linux Plumbers Conference / LinuxCon that included discussion of CLONE_FD. See the slides at https://events.linuxfoundation.org/sites/events/files/slides/fd_0.pdf https://events.linuxfoundation.org/sites/events/files/slides... .
- vezzy-fnord 11y ago
  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.

by i336_ 11y ago

JoshTriplett 11y ago

Identifying processes with file descriptors instead of PIDs, initially by adding a new flag to clone, CLONE_FD, that gives you back a file descriptor for the new process. The descriptor becomes readable when the process exits, so you can manage a child process and get its status without SIGCHLD. That allows a library to manage child processes without messing with the signal handlers of the parent process using the library. Since the file descriptor holds a reference to the kernel data structure for a process (task_struct), that makes it race-free, unlike a PID (for anyone other than the parent process), and thus unlike a path within /proc (which uses the PID). So after getting CLONE_FD in, and adding ways to use a file descriptor in place of a PID in other syscalls, I'd like to add ways to use that process file descriptor to get back information about the process instead of using /proc (such as via ioctls). While there's sadly no video available, I gave a presentation at Linux Plumbers Conference / LinuxCon that included discussion of CLONE_FD. See the slides at https://events.linuxfoundation.org/sites/events/files/slides/fd_0.pdf https://events.linuxfoundation.org/sites/events/files/slides... .

vezzy-fnord 11y ago
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.