Hello, On Mon, Feb 11, 2013 at 11:50 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Jaroslav Reznik wrote:
These days, most privileged system operations are already controlled by polkit, a well-established
(I'll just briefly note how much polkit has changed since then...)
For directly executed tools, polkit provides a setuid-root helper program called ‘’pkexec’’.
and in the details:
python: put a pkexec invocation in the wrapping shell script C tools: re-exec with pkexec in C code C tools: move original to /usr/lib/<pkg>/<tool>, and wrap /usr/bin/<tool> with a pkexec shell script (ugly!)
This is falling WAY short of the advertising! pkexec entirely defeats the purpose of using PolicyKit! Instead of having a specific permission, such as org.kde.kcontrol.kcmclock.save, which admins can give to their users in good conscience (even if they do NOT trust them to do anything OTHER than the fine-grained allowance the permission represents), you have a org.freedesktop.policykit.exec permission which is trivially equivalent to root access (because it allows you to execute arbitrary code as any user including root). Therefore, you degrade PolicyKit into a device to prompt for the root password (or a wheel user password, the sudo way). It is impossible to give out fine-grained permissions this way. I don't see what "access control policy" other than auth_admin you'd define for org.freedesktop.policykit.exec in an "enterprise environment"; surely you aren't planning to give your users root access!
pkexec can use fine-grained action configuration limited to a specific executable. It's even described on the feature page in the "How to Convert" section, right below the section you quoted. (True, the feature page describes it as a way to add the ...exec.allow_gui annotation, but the ability to give a separate name and defaults is equally important.)
We need a feature to actually use PolicyKit the way it was intended, phasing out usermode, consolehelper, kdesu and pkexec all at once wherever it is possible.
That Would Be Nice™ as well, even though it is more work (especially if it also resulted in a stable and documented API for the privileged part). Three years ago bugs were filed against some of the affected components. Mirek