kernel-wishlist: move completed items to the end

Author: poettering

README.md

@@ -135,52 +135,6 @@ entirely read-only. To close this gap it would be great if such
 propagated mounts could implicitly gain `MS_RDONLY` as they are
 propagated.
 
-### Disabling reception of `SCM_RIGHTS` for `AF_UNIX` sockets
-
-[x] Ability to turn off `SCM_RIGHTS` reception for `AF_UNIX`
-sockets.
-
-**🙇 `77cbe1a6d8730a07f99f9263c2d5f2304cf5e830 ("af_unix: Introduce SO_PASSRIGHTS")` 🙇**
-
-Right now reception of file descriptors is always on when
-a process makes the mistake of invoking `recvmsg()` on such a
-socket. This is problematic since `SCM_RIGHTS` installs file
-descriptors in the recipient process' file descriptor
-table. Getting rid of these file descriptors is not necessarily
-easy, as they could refer to "slow-to-close" files (think: dirty
-file descriptor referring to a file on an unresponsive NFS server,
-or some device file descriptor), that might cause the recipient to
-block for a longer time when it tries to them. Programs reading
-from an `AF_UNIX` socket currently have three options:
-
-1. Never use `recvmsg()`, and stick to `read()`, `recv()` and
-   similar which do not install file descriptors in the recipients
-   file descriptor table.
-
-2. Ignore the problem, and simply `close()` the received file descriptors
-   it didn't expect, thus possibly locking up for a longer time.
-
-3. Fork off a thread that invokes `close()`, which mitigates the
-   risk of blocking, but still means a sender can cause resource
-   exhaustion in a recipient by flooding it with file descriptors,
-   as for each of them a thread needs to be spawned and a file
-   descriptor is taken while it is in the process of being closed.
-
-(Another option of course is to never talk `AF_UNIX` to peers that
-are not trusted to not send unexpected file descriptors.)
-
-A simple knob that allows turning off `SCM_RIGHTS` right reception
-would be useful to close this weakness, and would allow
-`recvmsg()` to be called without risking file descriptors to be
-installed in the file descriptor table, and thus risking a
-blocking `close()` or a form of potential resource exhaustion.
-
-**Use-Case:** any program that uses `AF_UNIX` sockets and uses (or
-would like to use) `recvmsg()` on it (which is useful to acquire
-other metadata). Example: logging daemons that want to collect
-timestamp or `SCM_CREDS` auxiliary data, or the D-Bus message
-broker and suchlike.
-
 ### Filtering on received file descriptors
 
 An alternative to the previous item could be if some form of filtering
@@ -191,27 +145,6 @@ received" may be expressed. (BPF?).
 
 **Use-Case:** as above.
 
-### A reliable way to check for PID namespacing
-
-[x] A reliable (non-heuristic) way to detect from userspace if the
-current process is running in a PID namespace that is not the main
-PID namespace. PID namespaces are probably the primary type of
-namespace that identify a container environment. While many
-heuristics exist to determine generically whether one is executed
-inside a container, it would be good to have a correct,
-well-defined way to determine this.
-
-**🙇 The inode number of the root PID namespace is fixed (0xEFFFFFFC)
-and now considered API. It can be used to distinguish the root PID
-namespace from all others. 🙇**
-
-**Use-Case:** tools such as `systemd-detect-virt` exist to determine
-container execution, but typically resolve to checking for
-specific implementations. It would be much nicer and universally
-applicable if such a check could be done generically. It would
-probably suffice to provide an `ioctl()` call on the `pidns` file
-descriptor that reveals this kind of information in some form.
-
 ### Excluding processes watched via `pidfd` from `waitid(P_ALL, …)`
 
 **Use-Case:** various programs use `waitid(P_ALL, …)` to collect exit
@@ -1007,3 +940,70 @@ handlers.
 **🙇 `bc70682a497c ("ovl: support idmapped layers")` 🙇**
 
 **Use-Case:** Allow containers to use `overlayfs` with idmapped mounts.
+
+### Disabling reception of `SCM_RIGHTS` for `AF_UNIX` sockets
+
+[x] Ability to turn off `SCM_RIGHTS` reception for `AF_UNIX`
+sockets.
+
+**🙇 `77cbe1a6d8730a07f99f9263c2d5f2304cf5e830 ("af_unix: Introduce SO_PASSRIGHTS")` 🙇**
+
+Right now reception of file descriptors is always on when
+a process makes the mistake of invoking `recvmsg()` on such a
+socket. This is problematic since `SCM_RIGHTS` installs file
+descriptors in the recipient process' file descriptor
+table. Getting rid of these file descriptors is not necessarily
+easy, as they could refer to "slow-to-close" files (think: dirty
+file descriptor referring to a file on an unresponsive NFS server,
+or some device file descriptor), that might cause the recipient to
+block for a longer time when it tries to them. Programs reading
+from an `AF_UNIX` socket currently have three options:
+
+1. Never use `recvmsg()`, and stick to `read()`, `recv()` and
+   similar which do not install file descriptors in the recipients
+   file descriptor table.
+
+2. Ignore the problem, and simply `close()` the received file descriptors
+   it didn't expect, thus possibly locking up for a longer time.
+
+3. Fork off a thread that invokes `close()`, which mitigates the
+   risk of blocking, but still means a sender can cause resource
+   exhaustion in a recipient by flooding it with file descriptors,
+   as for each of them a thread needs to be spawned and a file
+   descriptor is taken while it is in the process of being closed.
+
+(Another option of course is to never talk `AF_UNIX` to peers that
+are not trusted to not send unexpected file descriptors.)
+
+A simple knob that allows turning off `SCM_RIGHTS` right reception
+would be useful to close this weakness, and would allow
+`recvmsg()` to be called without risking file descriptors to be
+installed in the file descriptor table, and thus risking a
+blocking `close()` or a form of potential resource exhaustion.
+
+**Use-Case:** any program that uses `AF_UNIX` sockets and uses (or
+would like to use) `recvmsg()` on it (which is useful to acquire
+other metadata). Example: logging daemons that want to collect
+timestamp or `SCM_CREDS` auxiliary data, or the D-Bus message
+broker and suchlike.
+
+### A reliable way to check for PID namespacing
+
+[x] A reliable (non-heuristic) way to detect from userspace if the
+current process is running in a PID namespace that is not the main
+PID namespace. PID namespaces are probably the primary type of
+namespace that identify a container environment. While many
+heuristics exist to determine generically whether one is executed
+inside a container, it would be good to have a correct,
+well-defined way to determine this.
+
+**🙇 The inode number of the root PID namespace is fixed (0xEFFFFFFC)
+and now considered API. It can be used to distinguish the root PID
+namespace from all others. 🙇**
+
+**Use-Case:** tools such as `systemd-detect-virt` exist to determine
+container execution, but typically resolve to checking for
+specific implementations. It would be much nicer and universally
+applicable if such a check could be done generically. It would
+probably suffice to provide an `ioctl()` call on the `pidns` file
+descriptor that reveals this kind of information in some form.