Replacing polkit JS backend

[Ikey Doherty]

Apologies, been epically busy here over at Solus.
I've not done the PKLA parser and test suite yet,
I can spend time on that this weekend if you wish.

- ikey

On 15/12/17 22:23, Michael Biebl wrote:
> Hi Ikey,
> 
> I'd be very interested to hear updates on your efforts.
> Has there been progress or did you run into issues?
> 
> Regards,
> Michael
> 
> 2017-10-20 17:10 GMT+02:00 Ikey Doherty <ikey at solus-project.com>:
>> Hi,
>>
>> I'm Ikey Doherty, leader of the Solus project [1].
>> Yep, I know, yet another thread about replacing mozjs in polkit!
>> Anyway, we've opted to tear out the existing JS backend entirely
>> in Solus [2] - but we're not putting any JS providers back in.
>>
>> Instead we're going with a simpler, statically defined text format.
>> This is "compiled" into a chain of structs when loaded, and policy
>> tests are chained along file->policy->next file->next until such
>> point as a break is achieved (i.e. not UNHANDLED)
>>
>> This is being actively developed right now, and we made a bit of noise
>> about it on G+, so I'm here for two reasons.
>>
>> 1) Dispell rumours. We're not interested in a complete fork of polkit.
>> 2) Explain the situation.
>>
>> I've seen a number of polkit alternatives spring up (such as Ostro's
>> groupcheck) - however none still maintain full compatibility. Solus,
>> being a desktop distro, still needs polkit agent, and the relevant
>> API/ABI.
>>
>> Each rule will have a .desktop style file, which everyone loves [3],
>> with well defined fields. Each rule may yield a Result when all of
>> the specified conditions are met. A rule may also yield a ResultInverse
>> as a blocking chain, however the action ID must first be matched:
>>
>>     [Policy]
>>     Rules=libvirt.rules;
>>     AdminRules=polkit-default.admin
>>
>>     [polkit-default.admin]
>>     InUnixGroups=wheel
>>     # InNetGroups=blah
>>
>>     [libvirt.rules]
>>     Actions=org.libvirt.unix.manage
>>     InUnixGroups=libvirt
>>     Result=yes
>>     # Explicitly set a result if the condition is NOT matched
>>     # ResultInverse=auth_self_keep
>>
>> There are also fields to replace "subject.$field" accessors, i.e.:
>>
>> SubjectActive=true
>> SubjectLocal=true
>>
>> Unlike a normal INI mapping, we don't test **defaults**. Instead, if
>> the key is set to a value (true or false) we set a flag to our struct
>> evaluation (policy->constraints & PF_CONSTRAINT_SUBJECT_ACTIVE) to
>> make us validate against whatever the value is, offering the chance for
>> a plain text file to be highly expressive.
>>
>> Our intention is that when this work is complete and tested in Solus,
>> we'll want to upstream this. If the polkit development community is not
>> interested in this, that's OK - we'll continue to carry the patches in
>> Solus. However I would like to see this ideally in polkit itself, and
>> dismiss the need for forks and alternatives, making polkit lightweight
>> once more and even suitable for embedded environments.
>>
>> Anyway, rambly post over, I'd much rather be straight up early about
>> what we're doing, before the rumour mill goes insane and thinks we're
>> forking polkit permanently. :)
>>
>> Cheers!
>>
>> - ikey
>>
>>
>>
>> [1] https://solus-project.com/
>> [2] https://dev.solus-project.com/T4824
>> [3] Unless you use QSettings.
>> _______________________________________________
>> polkit-devel mailing list
>> polkit-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
> 
> 
>