On Mon, 2009-05-04 at 21:06 +0200, Michael Biebl wrote: > That basically reads, like you are missing proper documentation. > Have you installed policykit-doc and read the documentation provided there > (best > read with devhelp)? [...] > We invented groups like plugdev/netdev/powerdev in HAL, to control access to > the > HAL D-Bus service. Yet the exact meaning of those groups is very vague (or can > you tell me which privileges you exactly get by being a member of e.g. group > plugdev?) [...] > Again, the group-based approach is less flexible, too coarse grained, not > dynamic and not scalable. Thus PolicyKit is a definit improvement (security > wise). [...] > What I miss from your arguments are solid, technical reasons, why PolicyKit > is, > as you put it, "a bad idea".
Based on your comments, I think you misunderstand me. I don't think PolicyKit is a bad idea, and I agree that the groups previously used were too coarsely grained and too unclear about what privileges were granted through them. What I do think is a bad idea is installing policykit by default, as a hard dependency of HAL. Even if I don't know exactly what privileges are granted through the `plugdev' group, I do know for sure that without being a member of it, no privileges at all are granted, which is something I cannot necessarily know with PolicyKit. In fact, I installed policykit-doc, as you suggested, and from reading it, it seems that it is the inidividual packages that grant privileges by default simply by installing policy files into /usr/share/PolicyKit/policy. For example, merely by having NetworkManager installed, local users would automatically be granted privilege to change networks, whereas previously, I would have to make them part of the netdev group, explicitly. My point, therefore, is that since the installation of PolicyKit grants privileges to users merely by virtue of being installed, it should not be installed automatically. If it is installed automatically, I should at least have to turn it on explicitly. Fredrik Tolf -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
