Replacing polkit JS backend

[Ikey Doherty]

OK I've got some initial rough patchwork hovering on GitHub:

https://github.com/ikeydoherty/polkit-no-script/tree/noscript-3

https://github.com/ikeydoherty/polkit-no-script/commit/5bcb1c1f9f678d950c44eccba81db36fddb09efc

I've opted to make it an **alternative** backend to ease migration,
thus:

 --with-backend=js|keyfile

I'm linking purely in case folks wanna have a look at it early.
Right now certain things aren't finished and I need to do the
test suites + documentation, and add Vars support to the format,
so once that's all done I'll send a formal RFC patch to the list.

I opted to make InUserNames -> InUnixNames for consistency with
the existing InUnixGroups.

- ikey

N.B We're now using this in Solus so it's already getting testing miles
on it.

On 20/10/17 17:29, Jeremy Linton wrote:
> Hi,
> 
> As a short term solution, there are patches to move to to mozjs38.
> 
> https://www.mail-archive.com/polkit-devel@lists.freedesktop.org/msg00499.html
> 
> 
> I've recently been encouraged to do the port to mozjs52 as well,
> although my personal opinion is that javascript is way overkill for what
> polkit needs.
> 
> 
> 
> On 10/20/2017 10:57 AM, Ikey Doherty wrote:
>>
>>
>> On 20/10/17 16:49, Simon McVittie wrote:
>>> On Fri, 20 Oct 2017 at 16:10:24 +0100, Ikey Doherty wrote:
>>>> Our intention is that when this work is complete and tested in Solus,
>>>> we'll want to upstream this.
>>>
>>> (For avoidance of doubt, I do not consider myself to be a polkit
>>> maintainer and am not in a position to accept or reject your design
>>> proposal. I personally think it looks like it has potential, and will
>>> be interested to see what happens.)
>>>
>>> I think the point at which you're ready to ship this to your users seems
>>> considerably too late to upstream it: if the polkit maintainers are
>>> interested in this design change in principle, but review raises design
>>> issues in the "API" that cannot be resolved in a compatible way, then
>>> you'll be stuck with a difficult decision between breaking compatibility
>>> for your users, or being forever incompatible with upstream polkit
>>> (maintaining a fork whether you wanted to be or not).
>>
>> We manage all the polkit files in Solus already, so if changes are
>> required we'll adapt them. We're rolling release so its trivial to
>> do this.
>>
>>>
>>> I would suggest proposing the app- and user-facing "APIs" for review as
>>> soon as you consider them to be reasonably well-thought-out, even if
>>> the detailed implementation is only reviewed when finished.
>>
>> Of course - 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.
>>
>>>
>>> Of course, it is possible that the reaction will be "you touched it
>>> last,
>>> you maintain it now" :-)
>>
>> That's a risk I understand, but that's fine too. I could always follow
>> up with the oblig. convert to meson patches, given that its glib. :P
>>
>>>
>>> How do these keyfile-based policies compare with the old (polkit 0.105)
>>> keyfile-based policies, which e.g. Debian and Ubuntu are still shipping?
>>
>> Similar to the pkla but uses explicit fields to be expressive, i.e.:
>>
>> InUnixGroups=
>> InUserNames=
>>
>> vs pkla:
>>
>> AdminIdentities=unix-user:bob
>>
>> It's simpler to parse, and does away with the JSisms. It also allows to
>> do magic like:
>>
>> [livecd.rules]
>> Action=*
>> InUserNames=live
>> InUnixGroups=%wheel%
>> Active=true
>> Result=yes
>>
>> or:
>>
>> [blacklist.rules]
>> ActionContains=.udisks.
>> InUnixGroups=guest
>> Result=no
>>
>>>
>>> Regards,
>>>      smcv
>>> _______________________________________________
>>> polkit-devel mailing list
>>> polkit-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>>>
>> _______________________________________________
>> polkit-devel mailing list
>> polkit-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>>
>