On Fri, Mar 31, 2006 at 12:17:19PM -0500, David Zeuthen wrote:
> Well, I'm sure that auth-as-self just because you are in a specific
[^not, as per your reply to yourself]
> group is the answer here. Basically the thinking right now for PolicyKit
I don't think it should be _just because_, but I think that should be one
way of describing who gets what. Not opposed to having other ways as well,
but again in general I prefer to see "how can we make this work with
existing mechanisms" rather than "oooh, shiny new wheels".
> 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)
FWIW, The shadow-utils pacakge provides the later for Unix supplementary
groups have a mechanism through the 'gpasswd' command, which can allow an
otherwise unprivledged user to manage group membership.
--
Matthew Miller mattdm@xxxxxxxxxx <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
