On Monday, November 12, 2012 12:27:52 PM Dan Williams wrote: > On Sat, 2012-11-10 at 02:33 +0100, Kevin Kofler wrote: > > Matthew Miller wrote: > > > Apparently the new version of polkit brings in javascript. The js > > > package > > > is 6.5MB. I think anything that uses polkit will depend on it -- can we > > > remove it from core? > > > > Of course, the real question is why the heck PolicyKit needs a Turing- > > complete rule language (which also forced everyone to port their existing > > rules) when the previously-used simple INI-style pkla rule format did the > > job just fine! > > So that more complex rules-parsing can be done instead of hardcoded > rules. For example, when creating a new WiFi network, NetworkManager > could pass along the security options, network details, even the user > that requested creating it. Administrator-written rules can factor all > those details into the decision whether to allow/deny, which the > existing static rules simply cannot do. except that most admins will never be able to do this. The only people that get any flexibility are people who manage their own system. Everyone else likely has some compliance issues and they have to be verifiably in configuration. What will happen is the generic js file will be SHA256 hashed and we'll check the file's hash in SCAP and report the system as out of configuration. IOW, anyone running any sizeable operation just lost any flexibility. > Whether or not JS should be a *hard* dependency of PolicyKit, I don't > know. But the feature is valuable, so don't dismiss it out-of-hand. I think its a bad idea to have too much flexibility for access control systems. They have to be verifiable. If you have to comply to PCI-DSS or the DISA STIG or any other standard, you have to be able to demonstrate you are in the approved config. No one can write a test that can tell if the rules really are sound. So, what will happen is one set will be chosen for better or worse, it will be SHA256 hashed. And no one can change anything in it without being out of compliance. The benefit of the name=value setup is that we can pick out the things that matter and skip everything else which truly gives flexibility when needing to demonstrate compliance. -Steve -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
