Pidfd

(10 intermediate revisions by the same user not shown)

Line 1:

Since [[Linux_APIs|Linux 5.2]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.

Since [[Linux_APIs|Linux 5.1]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.

At the heart of the pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with <tt>clone3(2)</tt>.

The first "pidfds" were created by opening a <tt>/proc/PID</tt> directory, and used with <tt>pidfd_send_signal(2)</tt>. These pidfds are now considered incomplete (they cannot be polled for process termination, nor can they be used with the <tt>waitid(2)</tt> system call).

==Kernel==

At the heart of the modern pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with <tt>clone3(2)</tt>.

Kernel 5.3 introduced <tt>pidfd_open(2)</tt>, allowing a pidfd to be opened for an arbitrary existing process. If you for some reason can't use <tt>clone3(2)</tt>, this can be employed together with <tt>fork(2)</tt> for a race-free pidfd acquisition on children (see <tt>pidfd_spawn(3)</tt> below).

Kernel 5.6 added <tt>pidfd_getfd(2)</tt>, supporting duplication of an existing file descriptor in a process identified by a pidfd. This operation requires <tt>PTRACE_MODE_ATTACH_REALCREDS</tt>.

Kernel 5.8 added support for supplying a pidfd to <tt>setns(2)</tt>.

Kernel 5.10 brought <tt>process_madvise(2)</tt>, generalizing <tt>madvise(2)</tt> to multiple memory regions and allowing it to be applied to another process's address space. When used on another process (as opposed to oneself), it requires <tt>PTRACE_MODE_READ_FSCREDS</tt> and <tt>CAP_SYS_NICE</tt>.

As of 6.5, credentials can be sent using pidfds rather than <tt>SCM_CREDENTIALS</tt>-style PIDs using the <tt>SCM_PIDFD</tt> type. <tt>getsockopt(2)</tt> can use <tt>SO_PEERPIDFD</tt> to get a pidfd for the peer process on a <tt>unix(7)</tt> socket.

6.9 introduces pidfdfs, a pseudo filesystem similar to nsfs. This is not visible from userspace, and is not mounted. It facilitates system calls which demand a filesystem backing: <tt>statx()</tt> now works, as do LSMs (Linux Security Modules).

==[[Glibc]]==

GNU libc added pidfd system call support in 2.36. Glibc 2.39 added two functions for pidfds, complementing <tt>posix_spawn(3)</tt>. They return pidfds rather than PIDs:

* <tt>pidfd_spawn(3)</tt>: analogous to <tt>posix_spawn(3)</tt>

* <tt>pidfd_spawnp(3)</tt>: analogous to <tt>posix_spawnp(3)</tt>

The <tt>posix_spawnattr_t</tt> argument allows (among other things) spawning the process within a different control group.

Also added was <tt>pidfd_getpid(3)</tt>:

* <tt>pid_t pidfd_getpid(3)</tt>: get the PID from a pidfd

==External links==

* [https://lwn.net/Articles/943022/ Race-free process creation in the GNU C library], LWN

* [https://lwn.net/Articles/943022/ GNU C Library version 2.39], LWN

* [https://lwn.net/Articles/963749/ A new filesystem for pidfds], LWN

[[Category: Linux]]

Pidfd: Difference between revisions

Dank (talk | contribs)

@@ Line 1: / Line 1: @@
-Since [[Linux_APIs|Linux 5.2]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.
+Since [[Linux_APIs|Linux 5.1]], pidfds have more or less allowed one to refer to a process using a file descriptor, making it possible to eliminate a set of race conditions and ambiguities.
-At the heart of the pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with <tt>clone3(2)</tt>.
+The first "pidfds" were created by opening a <tt>/proc/PID</tt> directory, and used with <tt>pidfd_send_signal(2)</tt>. These pidfds are now considered incomplete (they cannot be polled for process termination, nor can they be used with the <tt>waitid(2)</tt> system call).
+==Kernel==
+At the heart of the modern pidfd abstraction is the <tt>CLONE_PIDFD</tt> flag to the <tt>clone(2)</tt> system call (note that this recycles the deprecated <tt>CLONE_PID</tt> bit). It is not possible to use this flag with <tt>CLONE_THREAD</tt>, and thus the created process will always be a thread group leader. It cannot be used together with the (deprecated) <tt>CLONE_DETACHED</tt> flag. The resulting file descriptor is placed in <tt>parent_tid</tt> when used with <tt>clone(2)</tt> (and thus it cannot there be used together with <tt>CLONE_PARENT_SETTID</tt>) and <tt>cl_args.pidfd</tt> when used with <tt>clone3(2)</tt>.
+Kernel 5.3 introduced <tt>pidfd_open(2)</tt>, allowing a pidfd to be opened for an arbitrary existing process. If you for some reason can't use <tt>clone3(2)</tt>, this can be employed together with <tt>fork(2)</tt> for a race-free pidfd acquisition on children (see <tt>pidfd_spawn(3)</tt> below).
+Kernel 5.6 added <tt>pidfd_getfd(2)</tt>, supporting duplication of an existing file descriptor in a process identified by a pidfd. This operation requires <tt>PTRACE_MODE_ATTACH_REALCREDS</tt>.
+Kernel 5.8 added support for supplying a pidfd to <tt>setns(2)</tt>.
+Kernel 5.10 brought <tt>process_madvise(2)</tt>, generalizing <tt>madvise(2)</tt> to multiple memory regions and allowing it to be applied to another process's address space. When used on another process (as opposed to oneself), it requires <tt>PTRACE_MODE_READ_FSCREDS</tt> and <tt>CAP_SYS_NICE</tt>.
+As of 6.5, credentials can be sent using pidfds rather than <tt>SCM_CREDENTIALS</tt>-style PIDs using the <tt>SCM_PIDFD</tt> type. <tt>getsockopt(2)</tt> can use <tt>SO_PEERPIDFD</tt> to get a pidfd for the peer process on a <tt>unix(7)</tt> socket.
+.9 introduces pidfdfs, a pseudo filesystem similar to nsfs. This is not visible from userspace, and is not mounted. It facilitates system calls which demand a filesystem backing: <tt>statx()</tt> now works, as do LSMs (Linux Security Modules).
+==[[Glibc]]==
+GNU libc added pidfd system call support in 2.36. Glibc 2.39 added two functions for pidfds, complementing <tt>posix_spawn(3)</tt>. They return pidfds rather than PIDs:
+* <tt>pidfd_spawn(3)</tt>: analogous to <tt>posix_spawn(3)</tt>
+* <tt>pidfd_spawnp(3)</tt>: analogous to <tt>posix_spawnp(3)</tt>
+The <tt>posix_spawnattr_t</tt> argument allows (among other things) spawning the process within a different control group.
+Also added was <tt>pidfd_getpid(3)</tt>:
+* <tt>pid_t pidfd_getpid(3)</tt>: get the PID from a pidfd
+==External links==
+* [https://lwn.net/Articles/943022/ Race-free process creation in the GNU C library], LWN
+* [https://lwn.net/Articles/943022/ GNU C Library version 2.39], LWN
+* [https://lwn.net/Articles/963749/ A new filesystem for pidfds], LWN
+[[Category: Linux]]