Hi, This sounds pretty cool. I'm interested in some details: On Thu, Aug 13, 2009 at 2:28 PM, David Zeuthen<davidz@xxxxxxxxxx> 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: > > http://hal.freedesktop.org/docs/polkit/polkit.8.html > > 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: > > http://people.freedesktop.org/~david/pkexec-with-desktop-admin-r.png > > 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 time. > - 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". > - 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. -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list