Hello,
On Mon, Feb 11, 2013 at 11:50 PM, Kevin Kofler <kevin.kofler(a)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