Re: [PATCH net-next 1/3] scm: add SO_PASSPIDFD and SCM_PIDFD

[Lennart Poettering <mzxreary@0pointer.de>]

On Fr, 17.03.23 11:20, Christian Brauner (brauner@kernel.org) 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