Replacing polkit JS backend

[Ikey Doherty]

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.