<div dir="ltr">2018-01-03 19:47 GMT+01:00 Simon McVittie <span dir="ltr"><<a href="mailto:smcv@collabora.com" target="_blank">smcv@collabora.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 Wed, 03 Jan 2018 at 17:07:03 +0100, Miloslav Trmac wrote:<br>
> See one of the other mails, I’m worried that with the vaguely systemd-like ”no<br>
> programming language, but a few ‘simple’ special-cased condition operators”<br>
> systems never stay simple.<br>
<br>
</span>This is a valid concern.<br>
<span class=""><br>
> more and more Condition* operators which will be difficult to consume by any<br>
> automated analysis<br>
<br>
</span>True; but on the other hand, Turing-complete programming languages are<br>
difficult to analyze too, and impossible to consume without executing them<br>
(if nothing else because of the halting problem).<br></blockquote><div><br></div><div>Oh, I am absolutely not defending the JavaScript. I’m trying to argue that the policy language should be extremely simple and nonextensible. Extensibility should belong in the application logic deciding which policy element to apply. (And to be fair, there is a counterargument in that RBAC models sometimes force admins to autogenerate thousands or more ACL entries to express a “simple little program”.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I view the centralized "send all data about the operation to a central daemon,<br>
> and have a central generalized mechanism to make a decision" model as a mistake<br>
> from the start. It seems much more natural to me if "the qemu driver object in<br>
> libvirt, read access" conceptually had a dumb ACL attached. (That ACL could<br>
> still be centrally stored, or at least centrally enumeratable, if that seemed<br>
> like a valuable property to someone; I don’t see a strong case for it so far.)<br>
<br>
</span>So instead of (e.g.) libvirtd using libpolkit-gobject-1 to talk to polkit,<br>
which might talk to the polkit prompting agent before replying, you'd make<br>
libvirtd use libsome-new-policy, which might either answer "yes" or "no"<br>
immediately, or talk to the active user's prompting agent directly<br>
if the answer is "you need to ask"?<br></blockquote><div><br></div><div>This is not primarily an <i>implementation</i> preference. That libsome-new-policy could also forward all processing to a central ACL-storing and ACL-evaluating daemon. That’s an implementation detail as far as applications are concerned; as you say, e.g. maybe for privacy reasons the traditional polkit “is user X currently physically at the console” data point, or other data necessary to evaluate ACLs, should not be available for random processes to read. Also auditing, or perhaps other concerns may force the ACL evaluation to happen in a central place.</div><div><br></div><div>The point is that the proposed <i>model</i> is "this printer has a pretty dumb ACL for users who are allowed to print; here is a handle to the ACL, and a handle to the client asking to print; is this allowed?", not “there is a print-to-printer operation; here is a string:string map with a thousand details about the users’ connection and printer attributes, and BTW also a handle to the client asking to print; is this allowed?”  The application specifics become a matter of the application deciding which ACL to refer to, not a data point for the ACL language to interpret. (In theory this could tempt some applications to design their private “which ACL to use for this operation” programming language, which would be worse than a central one in polkit. My hope is that nobody would do that.)</div><div>    Mirek</div></div></div></div>