Replacing polkit JS backend

[Ikey Doherty]

Reply is down thar ->

On 21/10/17 19:39, Michael Biebl wrote:
> Hi!
> 
> 
> 2017-10-21 19:28 GMT+02:00 Matthew Miller <mattdm at mattdm.org>:
>> On Sat, Oct 21, 2017 at 03:40:40AM +0100, Ikey Doherty wrote:
>>> I've opted to make it an **alternative** backend to ease migration,
>>> thus:
>>>
>>>  --with-backend=js|keyfile
>>
>> Nice. I'm personally super in favor of it. Not speaking for Red Hat
>> officially, by any means. From a pure Fedora point of view...
>> I don't think we have many users taking advantage of the javascript
>> format, but if there are, I would prefer to not break them.
> 
> I'm very interested in this. I personally was never a huge fan of the
> JS based polkit version. mozjs is just a huge PITA.
> Martin Pitt, as co-maintainer of polkit in Debian, even less so, which
> is why all Debian and Ubuntu derived distros currently still use
> policykit 105 (+ a huge load of backported fixes).
> 
> So far, we didn't have many users which came to us asking for the
> additional flexibility provided by the js-based rules.
> The notable exception is the Debian postgresql maintainer who wanted
> to use the the more granular polkit filtering that systemd allows.
> See the PR Jasper mentioned.
> 
> Can something like this be expressed in the new keyfile format (at
> least to some extent)?

So to use the libvirt example:

polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.api.connect.getattr" &&
        subject.user == "berrange") {
          if (action.lookup("connect_driver") == 'QEMU') {
            return polkit.Result.YES;
          } else {
            return polkit.Result.NO;
          }
    }
});


You'd express that as follows (when all is complete)

[Policy]
Rules=libvirt.custom.rules

[libvirt.custom.rules]
Actions=org.libvirt.api.connect.getattr
InUnixUsers=berrange
ExpectedKeys=connect_driver
ExpectedValues=QEMU
Result=yes
ResultInverse=no

The idea was to avoid PKLAs use of "ResultActive" "ResultInactive"
stanzas, and instead make each rule condition based with a given
outcome. Rules can be layered with various conditions to handle
other cases too. Just dupe the rule and alter the conditions


> 
> That said, I'd be happy if this new keyfiles format would be something
> other distros (most notably Fedora/Redhat/openSUSE) could agree on. At
> least from the Debian side (and I assume by that extension Ubuntu)
> there definitely would be interest in having a common format again
> which is used by everyone and not as limited as the old pkla format.
> 
> Regards,
> Michael
> 

Aye, don't wanna repeat history, hence this new approach. Would also be
fantastic for upstream projects if they knew they could benefit from a
unified polkit format. (Another example being gvfs referencing 'wheel'
group which doesn't exist on all distros, hence the introduction of the
special '%wheel%' substitution)

- ikey