Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
Fredrik Tolf wrote: On Mon, 2009-05-04 at 09:52 +0200, Michael Biebl wrote: I have not researched it in detail yet, so I don't really know if it's a good So you are basing your request on FUD? I don't think so. What I meant by not researching was whether the solution of splitting it into two packages would be plausible. As for my wider argument, I may be wrong somewhere along the line, but please correct me if that is so. My argument is this: First, as far as I know, PolicyKit is essentially a system for granting privileges to a user which he would not have without it. In other words, depending on the configuration of PolicyKit, a user may be allowed to do things he would not be allowed to without it [see note 1]. Well, that is also true for the group based approach that was previously used in HAL, just much more coarse grained and less flexible and dynamic. Second, the configuration and operation of PolicyKit is not well-known, unlike normal Unix security. That basically reads, like you are missing proper documentation. Have you installed policykit-doc and read the documentation provided there (best read with devhelp)? But certainly documentation can always be improved. Third, Debian previously used ordinary Unix groups to assign various HAL-related privileges to users. Everyone known how Unix groups work; if a user wasn't a member of any particular groups, he would be granted no unexpected privileges. 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?) This is now replaced with PolicyKit. With the HAL policykit configuration file (you can inspect the HAL PolicyKit configuration with polkit-gnome-authorization), it is much clearer (and documented) what privileges are granted. 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. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
On Mon, 2009-05-04 at 23:12 +0200, Fredrik Tolf wrote: What I do think is a bad idea is installing policykit by default, as a hard dependency of HAL. Just in case I wasn't clear enough, my argument is this: Without PolicyKit, I had to take explicit action in order to grant privileges to users, while with PolicyKit, I have to take explicit action in order to *not* grant privileges to users. Therefore, it should not be installed by default, since the mere act of installing it suddenly gives all my existing users new privileges, without me, the administrator, even being warned of such a thing. Fredrik Tolf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526854: [Pkg-utopia-maintainers] Bug#526854: hal: HAL should not require PolicyKit
Fredrik Tolf [2009-05-04 21:37 +]: Just in case I wasn't clear enough, my argument is this: Without PolicyKit, I had to take explicit action in order to grant privileges to users, while with PolicyKit, I have to take explicit action in order to *not* grant privileges to users. That's not an inherent property of PK vs. groups, but a matter of default configuration. E. g. the installer used to put the default user into plugdev, powerdev, etc., and users-admin (from gnome-system-tools) did similar things for a desktop user. Likewise, there are PolicyKit privileges which you don't have as an user, for good reason (like mounting an internal hard disk). The job of us as a distro is to provide a sensible default configuration which provides a good balance between security and usability. For example, it doesn't make much sense to deny access to an USB camera or scanner to an user at a local console; he has physical access to those devices, after all. On the other hand, an user logging in through ssh should arguably not have these capabilities. Thus I am very much against making PK optional. It will only aggravate the confusion, since there will be systems which use PK and some which don't. History showed that device access privileges can't be sensibly mapped to and maintained with static group membership, so we should settle to _one_ system of verifying privileges, also to be compatible with the rest of the world. To be fair, I had very similar feelings like you when I heared about PK the first time, since it seemed to be that ominous new thing which opened root holes in the background. :-) Just my € 0.02, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
