Roles and Policy

Colin Walters walters at
Thu Aug 13 19:41:10 UTC 2009


This sounds pretty cool.  I'm interested in some details:

On Thu, Aug 13, 2009 at 2:28 PM, David Zeuthen<davidz at> wrote:
> Hey,
> I've just added a new subpackage in the polkit SRPM called
> polkit-desktop-policy. This package will add two new system groups (the
> trailing _r signifies these are really roles, not ordinary groups)
>  - desktop_admin_r
>  - desktop_user_r

Are these defined by upstream PolicyKit?  In other words, are these
group names expected to be the same across OS vendors?  Or just the
concept of the two groups, and their names can vary?

>  1. If the desktop_admin_r group is non-empty, then users in the group
>    are used for administrator authentication - see the polkit(8) man
>    page for details:
>    If the desktop_admin_r group is empty, we just ask for the root
>    password instead.
>    For example, the following is a screenshot where the users davidz
>    and bateman are in the desktop_admin_r group:
>  2. Second, if you are member of the desktop_admin_r group, then you
>    should be allowed to do a lot of things without being interrupted
>    by authentication dialogs. This part isn't complete, for now, it
>    includes
>      org.gnome.clockapplet.mechanism.* - set timezone and system time
>      org.freedesktop.devicekit.disks.* - all storage related things
>      org.freedesktop.RealtimeKit1.*    - run real-time processes
>    but we probably want to allow installing trusted packages, install
>    trusted updates and remove packages. Without asking for a password.
>    Probably more - Richard?

Hmmm.  I very, VERY strongly think that installing OS updates should
require no password by default in the unmanged case, and *especially*
not a different "root" password.  System time is probably in that area
as well.  If "make sound work without pops" requires the real-time
process permission, then we definitely need that too.

So it sounds like your desktop_admin_r is equivalent to the unmanaged
case?  And desktop_user_r is roughly...what?  Computer lab?  But
admins there aren't going to want people to be able to change the

>  - This should put an end to the (IMO misguided) request "please add
>   first user to the 'wheel' group". The new 'wheel' is
>   'desktop_admin_r' and the new sudo(1) is pkexec(1).

See, this is what I don't like, is that "admin" here really means
"execute arbitrary code as root" which I suggest we don't want to
conflate with "install OS updates" and "make sound work without

>  - With support in the OS installer for automatically adding the first
>   user to desktop_admin_r, we should be close to actually doing
>   installs without the concept of a root password...

The most important thing is to remove the root password from the
default UI flows,  But for example, the first time you typed "pkexec
vi /etc/resolv.conf" (i.e. do something arbitrary as uid 0) when
you're debugging some network problem, it'd be cool if that prompted
you for a root password.  In fact, if one wasn't set yet, offered to
let you set it.  Then we could axe the root password from the livecd
installer prompt, and it becomes on-demand.

More information about the Fedora-desktop-list mailing list