On Fr, 17.03.23 11:20, Christian Brauner (brauner@xxxxxxxxxx) wrote: > > > It seems that we already can use pidfd_open() (since linux-5.3), and > > > pass the resulting fd in af_unix SCM_RIGHTS message ? So yes, this is of course possible, but it would mean the pidfd would have to be transported as part of the user protocol, explicitly sent by the sender. (Moreover, the receiver after receiving the pidfd would then still have to somehow be able to prove that the pidfd it just received actually refers to the peer's process and not some random process. – this part is actually solvable in userspace, but ugly) The big thing is simply that we want that the pidfd is associated *implicity* with each AF_UNIX connection, not explicitly. A lot of userspace already relies on this, both in the authentication area (polkit) as well as in the logging area (systemd-journald). Right now using the PID field from SO_PEERCREDS/SCM_CREDENTIALS is racy though and very hard to get right. Making this available as pidfd too, would solve this raciness, without otherwise changing semantics of it all: receivers can still enable the creds stuff as they wish, and the data is then implicitly appended to the connections/datagrams the sender initiates. Or to turn this around: things like polkit are typically used to authenticate arbitrary dbus methods calls: some service implements a dbus method call, and when an unprivileged client then issues that call, it will take the client's info, go to polkit and ask it if this is ok. If we wanted to send the pidfd as part of the protocol we basically would have to extend every single method call to contain the client's pidfd along with it as an additional argument, which would be a massive undertaking: it would change the prototypes of basically *all* methods a service defines… And that's just ugly. Note that Alex' patch set doesn't expose anything that wasn't exposed before, or attach, propagate what wasn't before. All it does, is make the field already available anyway (the struct ucred .pid field) available also in a better way (as a pidfd), to solve a variety of races, with no effect on the protocol actually spoken within the AF_UNIX transport. It's a seamless improvement of the status quo. Lennart -- Lennart Poettering, Berlin
