<div dir="ltr">One more example for you, from gnome-initial-setup [0]. To give context on this scenario, gnome-initial-setup is acting as if it was the administrator in a restricted environment, guiding you through setting up your system, so it asserts authorization over its own actions. A fairly flexible whitelist of actions is used to sanity check that they're in the ballpark, but that's just an insurance policy.<div><br></div><div>I notice that Debian actually patches this to add an additional rule to the JavaScript -- is Debian shipping JS-based rules or not?<div><br></div><div>[0] <a href="https://git.gnome.org/browse/gnome-initial-setup/tree/data/20-gnome-initial-setup.rules">https://git.gnome.org/browse/gnome-initial-setup/tree/data/20-gnome-initial-setup.rules</a></div><div>[1] <a href="https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-initial-setup/debian/patches/polkit-allow-NM.patch?view=markup&pathrev=51145">https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-initial-setup/debian/patches/polkit-allow-NM.patch?view=markup&pathrev=51145</a></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 21, 2017 at 11:54 AM, Ikey Doherty <span dir="ltr"><<a href="mailto:ikey@solus-project.com" target="_blank">ikey@solus-project.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Reply is down thar -><br>
<span class=""><br>
On 21/10/17 19:39, Michael Biebl wrote:<br>
> Hi!<br>
><br>
><br>
> 2017-10-21 19:28 GMT+02:00 Matthew Miller <<a href="mailto:mattdm@mattdm.org">mattdm@mattdm.org</a>>:<br>
>> On Sat, Oct 21, 2017 at 03:40:40AM +0100, Ikey Doherty wrote:<br>
>>> I've opted to make it an **alternative** backend to ease migration,<br>
>>> thus:<br>
>>><br>
>>>  --with-backend=js|keyfile<br>
>><br>
>> Nice. I'm personally super in favor of it. Not speaking for Red Hat<br>
>> officially, by any means. From a pure Fedora point of view...<br>
>> I don't think we have many users taking advantage of the javascript<br>
>> format, but if there are, I would prefer to not break them.<br>
><br>
> I'm very interested in this. I personally was never a huge fan of the<br>
> JS based polkit version. mozjs is just a huge PITA.<br>
> Martin Pitt, as co-maintainer of polkit in Debian, even less so, which<br>
> is why all Debian and Ubuntu derived distros currently still use<br>
> policykit 105 (+ a huge load of backported fixes).<br>
><br>
> So far, we didn't have many users which came to us asking for the<br>
> additional flexibility provided by the js-based rules.<br>
> The notable exception is the Debian postgresql maintainer who wanted<br>
> to use the the more granular polkit filtering that systemd allows.<br>
> See the PR Jasper mentioned.<br>
><br>
> Can something like this be expressed in the new keyfile format (at<br>
> least to some extent)?<br>
<br>
</span>So to use the libvirt example:<br>
<br>
polkit.addRule(function(<wbr>action, subject) {<br>
    if (<a href="http://action.id" rel="noreferrer" target="_blank">action.id</a> == "org.libvirt.api.connect.<wbr>getattr" &&<br>
        subject.user == "berrange") {<br>
          if (action.lookup("connect_<wbr>driver") == 'QEMU') {<br>
            return polkit.Result.YES;<br>
          } else {<br>
            return <a href="http://polkit.Result.NO" rel="noreferrer" target="_blank">polkit.Result.NO</a>;<br>
          }<br>
    }<br>
});<br>
<br>
<br>
You'd express that as follows (when all is complete)<br>
<br>
[Policy]<br>
Rules=libvirt.custom.rules<br>
<br>
[libvirt.custom.rules]<br>
Actions=org.libvirt.api.<wbr>connect.getattr<br>
InUnixUsers=berrange<br>
ExpectedKeys=connect_driver<br>
ExpectedValues=QEMU<br>
Result=yes<br>
ResultInverse=no<br>
<br>
The idea was to avoid PKLAs use of "ResultActive" "ResultInactive"<br>
stanzas, and instead make each rule condition based with a given<br>
outcome. Rules can be layered with various conditions to handle<br>
other cases too. Just dupe the rule and alter the conditions<br>
<span class=""><br>
<br>
><br>
> That said, I'd be happy if this new keyfiles format would be something<br>
> other distros (most notably Fedora/Redhat/openSUSE) could agree on. At<br>
> least from the Debian side (and I assume by that extension Ubuntu)<br>
> there definitely would be interest in having a common format again<br>
> which is used by everyone and not as limited as the old pkla format.<br>
><br>
> Regards,<br>
> Michael<br>
><br>
<br>
</span>Aye, don't wanna repeat history, hence this new approach. Would also be<br>
fantastic for upstream projects if they knew they could benefit from a<br>
unified polkit format. (Another example being gvfs referencing 'wheel'<br>
group which doesn't exist on all distros, hence the introduction of the<br>
special '%wheel%' substitution)<br>
<span class="HOEnZb"><font color="#888888"><br>
- ikey<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
polkit-devel mailing list<br>
<a href="mailto:polkit-devel@lists.freedesktop.org">polkit-devel@lists.<wbr>freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/polkit-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/polkit-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">  Jasper<br></div>
</div>