Proposed F19 Feature: Usermode Migration

[Miloslav Trmač]

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