Dne 27.5.2012 19:05, Claudio Freire napsal(a):
On Sat, May 26, 2012 at 3:09 PM, Guido Berhoerster
wrote: Every admin would have their own user account, and that account would be a member of the group that has admin rights over the resource. That's how it has always been done in cli land, AFAIK, and that's how it ought to be done in the GUI too.
No, it isn't how it's done today with policykit nor is that how it should be done for the complex and fine-grained access control policy that is required here. We need roles as groups are much too limited and unsuitable for numerous reasons. The most important are that they are too coarse, difficult and inefficient to administer and inherently less secure. Roles allow fine-grained and centralized assignment of permissions to operations (rather than just filesystem objects) and improve security since they need to be explicitly assumed, possibly requiring authentication.
But what stops policykit from using group information?
I was not referring to filesystem-based permissions, I was talking about policykit checking group membership, as groups *are* roles.
Wouldn't we sooner or later run into the problem of the possible number of groups a user account can be member of? Not sure if it is an issue with current kernel, it's been ages since I last read kernel code... Jiri
But I'm intrigued by your assertion that groups are inherently less secure. Why? What would you propose to use instead? (links would be fine)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org