Roles and Policy

[Colin Walters]

On Thu, Aug 13, 2009 at 4:20 PM, David Zeuthen<davidz at redhat.com> wrote:

> The idea is that desktop_admin_r is for the owner(s) of the system - for
> example, the owner of a single-user laptop. The idea is that
> desktop_user_r is a non-owner or otherwise less privileged/trusted - for
> example, your kids on the shared computer system at home.

So my kids can't change the system time?  I dunno.  I think what we
need here is a wiki page which takes the current set of PolicyKit
actions (in the default desktop image only, i.e. not including say
virt-manager), and puts those actions into one of your two suggested
roles.

If we're talking about kids, I'd probably be more concerned about
usage-time limits or browser filtering, but neither of those fall
under PolicyKit.

> (And, btw, you _do need_ to enter the password for an admin user for
> 'pkexec bash' to work. Even if you are in desktop_admin_r. Ditto for
> installing untrusted/unsigned packages. And this is fine I think.)

Right, OK.  No strong opinion here on what those things should
require; we could make installing unsigned packages require you to do
a little dance in front of the webcam for all I care =)

> I think we want to completely disable the root account just like in OS X
> and Ubuntu. In my view, it just doesn't make sense to have a root
> password at all - shared secrets are really bad. One less password to
> worry about is really what you want.

I don't disagree that a root password is dumb for the unmanaged case.
But we do want to have a good story for people deploying computer
labs, and at least this is where Ubuntu's original "use sudo for
everything" kind of fails.  Also important here is the scenario where
a technical person maintains a friend's or family member's computer.
It should be easy for them to enable the root account and use it to
recover/administer the machine.