Replacing polkit JS backend

[Ikey Doherty]

Replying ->

On 20/10/17 17:20, Simon McVittie wrote:
> On Fri, 20 Oct 2017 at 16:57:55 +0100, Ikey Doherty wrote:
>> however the fact remains right now of nuking the dead mozjs
>> implementations actively from Solus, mozjs17 was dropped, now mozjs185
>> is kicked out (super dead) and git only supports mozjs24, again, very
>> dead. We're only allowing 38 + 52 to exist in Solus right now. Allowing
>> the older implementations to exist is a gaping security issue that we're
>> addressing, albeit with a large hammer.
> 
> I can understand the desire to hunt down old versions of mozjs (Debian
> would like to do the same), but a JavaScript interpreter is not
> *inherently* security-sensitive. A JS interpreter is only security-sensitive
> when it interprets JS obtained from untrusted sources. Given how polkit
> works, if your copy of polkit is interpreting untrusted JS, then you have
> far worse problems than the age of its mozjs implementation :-)
> 
> (From what I've seen of the mozjs build system, there are other reasons
> to want to run away from its older versions, though.)
> 
> In an attempt to keep track, here are the proposals I've seen for the
> future of polkit:
> 
> * keep JS, repeatedly update to latest mozjs (probably not viable long-term)
> * keep JS, switch intepreter to Duktape
> * go back to .pkla
> * your new keyfile backend
> 
> I wonder whether it would be feasible (for either upstream polkit
> or a transitional patchset in interested distros) to load .pkla into
> the same data structures as your new thing, effectively using it as
> a deprecated alternative syntax? One of the reasons Debian is still
> using .pkla (although not the only one AIUI) is that we don't have a
> particularly great compatibility story for what happens to sysadmins'
> locally-installed .pkla files.

I'm happy to do that, in theory we could just build up a set of
directories and check for the two suffixes, including the .pkla.
If we find a .pkla, populate the rule file with a different parser,
but still have the same rule evaluation methods.

The struct could easily support it, as it has fields like:

        gchar **unix_groups;
        gsize n_unix_groups;

        PolkitResponse response;
        PolkitResponse response_inverse;

        unsigned int constraints;

- ikey
> 
>     smcv
> _______________________________________________
> polkit-devel mailing list
> polkit-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>