remove polkit from core?

Steve Grubb sgrubb at redhat.com
Mon Nov 12 19:00:41 UTC 2012


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


More information about the devel mailing list