On Thu, 2006-03-30 at 17:26 -0500, Matthew Miller wrote: > > However, it's all work in progress at the point and since it's rather > > complex and deals with privilege escalation I've started writing a spec > > how all this is supposed to work. I'm not done yet with the spec.. but > > this is how far I've got > > http://webcvs.freedesktop.org/*checkout*/hal/PolicyKit/doc/spec/polkit-spec.html > > Okay, so no switching users at all. That looks pretty cool. I see "For > details (like what user to authenticate as) see XXX" -- it'd make me very > happy if XXX could include things like "for members of a given group, allow > auth-as-self" (as consolehelper currently does). Well, I'm sure that auth-as-self just because you are in a specific group is the answer here. Basically the thinking right now for PolicyKit is that this is defined on a per-privilege basis and we ship the OS with some sane defaults and the admin can change this later. So, for a given privilege (which, down the road, will include "changing the computer date/time", "mounting fixed disks", "use a webcam", "configure networking", "update OS with signed packages", "install signed software", "install unsigned software") the thinking is that the privilege in question specifies - if not authorized you auth either as yourself or as root - whether you may keep the privilege (for one time pain dialogs) - whether you may grant this privilege to other users (for one time pain dialogs) and that's basically it... One thing I may introduce later is the notion of "privilege profiles", e.g. the system can be put in e.g. the following profiles - Locked Down (everything requires auth) - Workstation (most things locked down, for example setting date and mounting removable drives requires auth) - Laptop (Most things not locked down, console users may set the time/date/timezone, mount both fixed and removable drives, update the OS with signed packages etc. without auth) - Unrestricted - (few things require auth; maybe not a good idea to include this at all) and a user goes into one of these profiles. I think that may solve what you need? Anyho, the nice thing is that the upstream packages using PolicyKit may define this policy themselves. For example, the GNOME clock applet authors would define policy (e.g. what is require to change the time/date/ timezone) for each of these profiles and I do think upstream is in a position to make such decisions better than a downstream distributor since they obviously are more familiar with the subject matter... (of course... a vendor like Fedora can always override this policy in the Fedora RPM).. But right now "privilege profiles" will only complicate the picture so I'm waiting a bit with these. But down the road I think this is what we're gonna if I can convince people (have to sell this to both upstream projects like GNOME, KDE and downstream like Fedora and other distros) that PolicyKit is a good idea... We'll see :-) One step at a time... David
