Roles and Policy

[David Zeuthen]

On Thu, 2009-08-13 at 20:55 +0200, Lennart Poettering wrote:
> On Thu, 13.08.09 14:28, David Zeuthen (davidz at redhat.com) wrote:
> 
> >  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 
> 
> rtkit should be accessible for normal desktop users already. Please
> move this to desktop_user_r!
> 
> I am assuming that this makes only sense if the upstream policy files
> in the various packages are more strict by default than what is
> shopped in polkit-desktop-policy. Right?

Right.

> So, for a package that has used console-based auth by default before
> (like rtkit), how should their upstream policy files be changed? How
> does console-based auth and this new role-based out fit together?

I think it really depends. We've always wanted the defaults specified in
the .policy files to, at least, be secure whilst also being usable. Now,
with this role mechanism being available, we can be a bit more strict.

For example, IIRC someones pet peeve was that we only required user
authentication, not admin authentication, for changing the system time.
He was concerned about some vague attack vector and log files and what
not. So to avoid endless discussions like that we're now changing this
to require admin authentication.

Either way, allowing any user at the console to use rtkit seems fine to
me so I would suggest not changing anything in rtkit. If people complain
we can always just change things later (e.g. 1. a new rtkit release with
other defaults in the .policy file; and 2. adding stuff for rtkit to
polkit-desktop-policy).

FWIW, this whole area is subject to much discussion - it's the classic
example trading off security for usability - and vice versa. But I, for
one, definitely want to move Fedora in a direction where there are fewer
authentication dialogs.

Hope this clarifies.

     David