Jaroslav Reznik wrote:
= Features/UsermodeMigration = https://fedoraproject.org/wiki/Features/UsermodeMigration
Feature owner(s): Harald Hoyer harald@redhat.com, Kay Sievers kay@redhat.com, Bill Nottingham notting@redhat.com
Access control of privileged operations for ordinary users should be handled exclusively by a centrally managed authority.
Usermode/consolehelper should be phased out and be replaced entirely by polkit.
So this feature advertises:
These days, most privileged system operations are already controlled by polkit, a well-established, fine-grained, (possibly) network-transparent service for managing privileged operations by ordinary users. Enterprise environments need to be able to centrally define access control policy for the organization, and automatically apply it to all connected workstations.
which is indeed how PolicyKit is intended to be used. See here the word "fine-grained". Then when you go at how the migration is actually supposed to be implemented, you see:
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!
I don't see why this misfeature was accepted for F18. It is entirely useless under this form. 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. (Of course, if the feature to be implemented really is "let the user run app 'foo' as root", then using pkexec or kdesu is a suitable solution.) Of course, this is much more work and often requires upstream cooperation (and probably a security audit! I've seen some "fine- grained" mechanisms which are no more secure (for non-auth_admin) in practice than org.freedesktop.policykit.exec). But using pkexec is just a quick hack to swipe the issue under the carpet and does not solve the real problem at all!
Kevin Kofler
I wrote:
I don't see why this misfeature was accepted for F18. It is entirely useless under this form. 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. (Of course, if the feature to be implemented really is "let the user run app 'foo' as root", then using pkexec or kdesu is a suitable solution.)
Oops, I misspoke there. What I meant is: (Of course, if the feature to be implemented really is "let the user run *a USER-SPECIFIED* app as root", then using pkexec or kdesu is a suitable solution.)
If you are trying to run a SPECIFIC app, e.g. system-config-foo, as root, then: 1. Even that could benefit from a more specific permission than org.freedesktop.policykit.exec, unless your app allows executing arbitrary code as root. AND 2. The problem is right there: running the whole app as root! That's NOT how PolicyKit is designed to work. It's a very coarse-grained and inflexible permission and you're running a lot more code as root than one needs to. (But of course, implementing a fine-grained model needs to be done right or the potential for abuse is even higher. E.g., you don't want a mechanism that claims to configure something specific and in reality accepts an arbitrary file to write to from the frontend, because then any user granted that permission can trivially exploit that mechanism with a fake frontend.) The whole point of PolicyKit was that you do NOT want to run the entire frontend app as root as was done in the past.
Kevin Kofler
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