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.
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.
https://gist.github.com/pothos/73dd4f7694acc3b6bbed614438f6e...