I wonder why it even is a setuid binary since there already is a privileged service it interacts with (through DBus). I think we should replace all setuid binaries with a scheme of having a privileged service that acts on the requests of unprivileged processes. With Unix Domain Sockets and SO_PEERCRED the unprivileged process user can be identified (but less info is available than with a setuid binary). This could even work with sudo but the difference is that the privileged service would not spawn a child process of the unprivileged process but rather hand out the stdin/err/out FDs of the spawned privileged process to the unprivileged process (or vice versa, get stdin/err/out FDs from the unprivileged process and set for the spawned privileged process), again this works with Unix Domain Sockets.
Nope because pkexec already is a privileged process because it is a setuid binary. Being a setuid binary instantly makes it a privileged process, it's not related to whether it's similar to sudo and does authorization. What I'm saying is that the pkexec process itself doesn't need to be setuid, it should be an unprivileged process (also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be when splitting this up in a daemon process).
Edit: Maybe to make it clear, yes, in theory the polkit project does follow the scheme of a privileged daemon process and unprivileged clients but in practice it doesn't because of the setuid polkit-agent-helper-1 and setuid pkexec programs.
You cannot accomplish sudo without setuid. Note that sudo means gaining privilege in the current context, with all its environment (including inherited file descriptors, the process group, etc.), not doing a privileged action at a distance.
> also true for the /usr/libexec/polkit-agent-helper-1 helper it uses which is a setuid binary but doesn't really have to be
Try making it non-setuid and see what happens.
(It will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.)
Right, process group and being child process gets lost when following this route. I think it's a compromise that is acceptable in many cases.
> [polkit-agent-helper-1] will fail to check your password because most mechanisms for doing so, like the usual pam_unix, are only accessible to root.)
That's what I mean, the helper itself could be unprivileged and hand the password over to a privileged daemon that does the check.
If you make the interface between unprivileged client and privileged server too complicated, eventually it will be more complicated than the interface of executing a setuid binary and potentially more likely to have bugs
