On Thu, 2009-08-13 at 15:41 -0400, Colin Walters wrote:
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?
Not yet. We might want a polkit-policy tarballs that define these roles (and possibly others) and the associated policy. I fwd'ed the original mail to polkit-devel-list for other distros to consider this.
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.
Right, so granting the authorization to install OS updates w/o a password for desktop_user_r and desktop_admin_r is what we want.
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 time.
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.
That's the _idea_ anyway. We might want to change this if we want to.
- 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 popping".
Right, so we just give this authorization only to desktop_admin_r. E.g. allow standard users to install trusted OS updates. Ditto for the rtkit stuff.
(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.)
- 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.
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.
David