<div dir="ltr">Hello,<div>2017-10-21 20:54 GMT+02:00 Ikey Doherty <span dir="ltr"><<a href="mailto:ikey@solus-project.com" target="_blank">ikey@solus-project.com</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 21/10/17 19:39, Michael Biebl wrote:<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></blockquote><div><br></div><div>See one of the other mails, I’m worried that with the vaguely systemd-like ”no programming language, but a few ‘simple’ special-cased condition operators” systems never stay simple. It’s easy and attractive to keep extending them with more and more Condition* operators which will be difficult to consume by any automated analysis, and potentially by users (e.g. in the above example, can "ExpectedKeys" and "ExpectedValues" have multiple values if they are plural? What is the separator? What is the escaping mechanism for including the separator inside the values? What is the semantics of N keys with M values?).</div><div><br></div><div>I view the centralized "send all data about the operation to a central daemon, and have a central generalized mechanism to make a decision" model as a mistake from the start. It seems much more natural to me if "the qemu driver object in libvirt, read access" conceptually had a dumb ACL attached. (That ACL could still be centrally stored, or at least centrally enumeratable, if that seemed like a valuable property to someone; I don’t see a strong case for it so far.)</div><div><br></div><div>Not that I know how to get from polkit to that ACL model…</div><div>    Mirek</div></div></div></div></div>