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
--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
