dbus issueshttps://gitlab.freedesktop.org/dbus/dbus/-/issues2023-11-22T17:34:57Zhttps://gitlab.freedesktop.org/dbus/dbus/-/issues/274Add GetConnectionUnixProcessIDHandle method2023-11-22T17:34:57ZPhilip WithnallAdd GetConnectionUnixProcessIDHandle methodSince the [kernel has gained more support for pidfds](https://lwn.net/Articles/794707/), Will Thompson suggested that it would be useful if D-Bus gained support for a `GetConnectionUnixProcessIDHandle` method to return one. This would be...Since the [kernel has gained more support for pidfds](https://lwn.net/Articles/794707/), Will Thompson suggested that it would be useful if D-Bus gained support for a `GetConnectionUnixProcessIDHandle` method to return one. This would be analogous to [`GetConnectionUnixProcessID`](https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-unix-process-id), but would return a pidfd (type `h`) rather than a PID.
This would only work on Unix, and only on kernels which support pidfds. It would return an error if pidfds aren’t supported by the kernel, and callers would presumably have to fall back to calling `GetConnectionCredentials` or whatever they used to do.
On success, the returned pidfd would remain open until the caller explicitly closed it, and could be used to track the remote peer without the usual race conditions relating to PID reuse.
The use of pidfds might potentially provide a way to reliably(ish) identify peer processes without needing an LSM, which is a typical roadblock to implementing that feature on many Linux systems (since many Linux systems don’t have LSMs). While it won’t make any of the information you can look up about a process more reliable, it will mean that a peer can at least be sure it’s looking up the right process.https://gitlab.freedesktop.org/dbus/dbus/-/issues/210Containers (#171): Last chance to change instance ID from 'o' to 'x'2023-10-20T12:35:46ZBugzilla Migration UserContainers (#171): Last chance to change instance ID from 'o' to 'x'One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an obj...One of the review comments on implementations of #171 that led to that issue stalling indefinitely was that some reviewers would prefer the container instance ID to be an opaque integer, probably `dbus_uint64_t` (`x`), rather than an object path.
See https://bugs.freedesktop.org/show_bug.cgi?id=106712 for the original discussion of this in a somewhat readable form (comments that were copied into this automatically-imported issue are not very readable).
We are constrained by some of the original implementation of Containers having been released in dbus 1.14.x. That version includes:
* `DBUS_HEADER_FIELD_CONTAINER_INSTANCE`, with value 10
* `dbus_bool_t dbus_message_set_container_instance(DBusMessage *, const char *)`
* `const char *dbus_message_get_container_instance (DBusMessage *)`
* The `const char *` in those C functions is documented as being an object path
So if we are going to convert the object path into an integer, we need to figure out a way to deprecate those and introduce an integer replacement.
We also should not make this change unless we have serious plans to introduce the ability to match signals against integers (#478).
@smcv is not particularly interested in this change, and so will not be working on it. If someone else wants this change, this is their chance to step forward to implement it.
## Deadline
If there is no substantial movement on this by the end of September 2023, then @smcv intends to reject this change and keep the container instance ID being an object path.
## Dependencies
@smcv will not accept this change unless someone (presumably someone who wanted this) steps forward to implement #478. It does not necessarily need to be finished before making this change.
/cc @dvdhrm @desrt