Replacing polkit JS backend

[Ikey Doherty]

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
>