Closed polkit-github-migration-bot closed 7 months ago
In gitlab.freedesktop.org by poettering on Oct 9, 2023, 19:35
/cc @bluca
In gitlab.freedesktop.org by bluca on Oct 30, 2023, 04:05
mentioned in commit bluca/polkit@531e378b36658d42f980b770d9158ac32a2b90c3
In gitlab.freedesktop.org by bluca on Nov 2, 2023, 14:35
mentioned in commit bluca/polkit@e04abe6762e5bf6b01e1b9cbc94b3ed3f6a3d9d5
In gitlab.freedesktop.org by bluca on Nov 29, 2023, 10:55
mentioned in commit bluca/polkit@35833abfe40a88088f885a36ce7031f818283e5c
In gitlab.freedesktop.org by jrybar on Dec 7, 2023, 17:32
Maybe I'm missing the larger context because I'm pretty far from being a systemd-code-aware, but I don't really understand the use case here.
Hooking up on DBus is one of the first things polkit does after starting the daemon and actually all communication between the subjects and authorities goes through DBus. Why would you even use polkit when dbus is not running yet?
Also, "authenticate arbitrary processes for actions"... Well, AFAIK the model is that subjects (programs asking for permission) ask the privileged programs whether they could do something and let polkit decide whether they can or not. How is "authenticate arbitrary processes for actions" meant in this context?
In gitlab.freedesktop.org by bluca on Dec 7, 2023, 17:47
Why would you even use polkit when dbus is not running yet?
Yeah that part is not really correct, but we do have things using varlink and not D-Bus at any time, not just at early boot
How is "authenticate arbitrary processes for actions" meant in this context?
The idea is to use this with the new thing I added to check if the caller is part of a systemd service. That works fine with D-Bus services as we can do PIDFD based auth, but we can't do that for something else - these varlink services. This fills that gap, so that you can ask via PIDFD whether any PIDFD passes some policy or not (ie: is it part of a specific systemd unit), rather than just asking about D-Bus peers.
In gitlab.freedesktop.org by poettering on Dec 7, 2023, 19:08
So we made the choice to expose various of ours service's IPC interfaces via Varlink rather than D-Bus since it has some benefits for us, as it just works during early boot, long before the dbus-broker showing up. Now, these services just stay around and are later accessible also for regular usespace, i.e. at a time D-Bus finally is available too.
Now, we'd like to hook up these services with polkit, so that they can authenticate their clients with it, but these clients have no D-Bus names, since they are Varlink clients after all, not D-Bus clients. Hence the request to authenticate by pidfd.
Of course, if these IPC services use polkit to authenticate a client then that authentication can only take place during late boot. But that's totally OK, the services should be able to deal with that just fine. Given that regular users (which are the kind you'd authenticate with Polkit) are not around during early boot anyway, we never even are tempted to authenticate anyone via Polkit. And even if that would happen then we'd try to connect to D-Bus, see that that doesn't work and hence refuse the client, because we cannot get an authentication from polkit that early.
I hope that makes some sense?
In gitlab.freedesktop.org by jrybar on Dec 8, 2023, 09:51
Perfectly. Thanks, guys.
This is solved and can be closed
In gitlab.freedesktop.org by poettering on Oct 9, 2023, 19:34
Link to the original issue: https://gitlab.freedesktop.org/polkit/polkit/-/issues/206 In systemd we'd like to authenticate arbitrary processes for actions, and reference the processes via pidfd. As I understand Polkit has some pidfd hookup in place already, but what's still missing afaics is that a dbus client can ask polkit to authenticate some process which is referenced by a pidfd for some action.
Usecase: in systemd we use an IPC that is not D-Bus in various contexts (specifcially: varlink IPC, because it must work before dbus is up, and various other reasons), but we'd still like to be able to authenticate clients via Polkit in some cases, if they are not privileged anyway. We can securely derive a pidfd from the connecting client, via the new kernel socket apis for that, but we cannot pass that on to polkit right now to ask it to authenticate that as a subject.