<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-08-13 20:12 GMT+02:00 Matthew Miller <span dir="ltr"><<a href="mailto:mattdm@mattdm.org" target="_blank">mattdm@mattdm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Aug 13, 2015 at 09:37:38AM -0700, Jasper St. Pierre wrote:<br>
> Is that really different from standalone releases of mozjs, which have<br>
> never been officially supported by Mozilla?<br>
<br>
</span>Are people really using / area we getting a lot of value from the<br>
javascript functionality at all? Is there any possiblity of going back<br>
to a more... bounded configuration system?<br></blockquote><br></div>4 packages use it on a pretty ordinary Fedora install; it seems the kinds of things they do are limited enough that they could be converted to a non-programming-language mechanism (the old .pkla as is, or perhaps with some additions to it). And then there is libvirt fully embracing this <a href="https://libvirt.org/aclpolkit.html">https://libvirt.org/aclpolkit.html</a> .<br><br></div><div class="gmail_extra">I would much prefer a “more bounded” permission system at these lower levels, but that would push the complexity/desire for customization up the stack to the callers, and we need to have a way to handle that. In my ideal world, all permissions system-wide on all objects are some kind of ACL (a set of (object, operation, group/role of subjects) tuples which are allowed to perform it; no deny facility, no ordering/priority issues), polkit is replaced by a library to evaluate such ACLs (possibly relying on daemons and OS services), and applications attach such ACLs to the objects they manage.<br><br></div><div class="gmail_extra">In practice ACLs with binary outcomes are a noticeable design limitation—what seems “conceptually the same operation” may need to be split into several distinct (or inheriting!) cases/ACLs, which requires more thinking  and more focus on users’ use cases in advance. In contrast, it is fairly simple to use the same polkit action names, give polkit a hash table with whatever information the service thinks <i>might</i> be useful, and let the user write arbitrary JS as they wish. (I think this would be a <i>good</i> design limitation, but it <i>is</i> noticeable, and the failure cases are not pretty: If the ACLs are designed incorrectly, users are left with somehow automating creation of dozens/thoustands/hundreds of thousands of them to get the policy they want; this is reportedly really happening in the industry.)<br><br></div><div class="gmail_extra">Having simplified polkit, or ideally those ACLs, but applications opting out of this and instead adding their own programmable authorization systems would not be an improvement.<br><br></div><div class="gmail_extra">(Of course, dropping JS would be breaking backward compatibility, which I <i>hate</i>. But that’s unavoidable in this subthread.)<br><br>Most importantly, I don’t want a distribution to sometimes process the 
rules and sometimes skip them depending on how the system is configured on a given hour, that would be disastrous for the ability 
to rely on deny rules.<br></div><div class="gmail_extra">    Mirek<i><br></i></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div></div>