Replacing polkit JS backend

[Michael Biebl]

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



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?