<div dir="ltr">Hello,<br><div class="gmail_extra">2017-12-18 11:05 GMT+01:00 Colin Walters <span dir="ltr"><<a href="mailto:walters@verbum.org" target="_blank">walters@verbum.org</a>></span>:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Based on some (long ago now) in-person discussion with the previous polkit maintainer:<br>
the JS backend was added for a reason from a real-world nontrivial in size desktop deployment.<br>
That said I don't have contact with them myself and unfortunately the original commit<br>
aeb2b50a7b0ed1411df81790231cd9<wbr>02d6e76e56<br>
doesn't give us any hints.  I wouldn't be surprised if they don't use it anymore.<br></blockquote><div><br></div><div>I tried tracking this down, and the best public record I can find is that the JS backend was motivated by <a href="https://bugs.freedesktop.org/show_bug.cgi?id=30181">https://bugs.freedesktop.org/show_bug.cgi?id=30181</a> , i.e. just adding the "other" field in the UNIX user/group/other ACL format — which was a pretty small patch compared to the JS backend (and polkit-pkla-compat does add that small patch).</div><div><br></div><div><br></div><div>Philosophically I think that most permissions on the system should mostly really be handled by a pretty dumb ACL library, with ACLs „attached to“ the individual objects they apply to (e.g. a printer daemon would record ACLs for printing to printers and managing the printer, and a global ACL for printer management). It should not look even a <i>tiny bit</i> like something programmable (once it is a <i>tiny</i> bit programmable, there will always be a good argument to make it <i>yet another tiny bit more</i> programmable, and we are back to Turing-completeness).</div><div><br></div><div>An audit tool should be able to statically and 100% reliably tell whether $operation is allowed to $user. Any Turing-complete, or less programmable but complex, model, makes writing such audit tools very hard to impossible.</div><div><br></div><div>Given an ACL library, a system-wide daemon may not even be necessary for evaluating ACLs as such; we would have a daemon for things like "is interactively logged in" and exposing them to the ACL system as pseudo-groups or something like that (and of course daemons for privilege escalations, e.g. to start D-Bus services running as root which can be used by non-root clients).</div><div><br></div><div>Yes, this is pretty similar to the Windows NT design back from….</div><div><br></div><div>Disclaimer: I haven’t extensively researched the academic literature, nor other permission models (and their later evolution like Windows restricted tokens) in this area. I may well be completely wrong about what is a good or reasonable design.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">At a practical level I think we'd have to ship both (really all 3) things for a while<br>
at least in Fedora; e.g.<br>
<a href="https://goldmann.pl/blog/2012/12/03/configuring-polkit-in-fedora-18-to-access-virt-manager/" rel="noreferrer" target="_blank">https://goldmann.pl/blog/2012/<wbr>12/03/configuring-polkit-in-<wbr>fedora-18-to-access-virt-<wbr>manager/</a><br>
and<br>
<a href="https://major.io/2015/04/11/run-virsh-and-access-libvirt-as-a-regular-user/" rel="noreferrer" target="_blank">https://major.io/2015/04/11/<wbr>run-virsh-and-access-libvirt-<wbr>as-a-regular-user/</a><br>
and variants are commonly used (I use that JS rule on this workstation too).<br></blockquote><div><br></div><div>Sadly, it’s not “for a while”. There is no practical path to migrate away from the JS backend <i>at all</i>. JS rules have the ability to ”reject” an action, so it is not <i>in general</i> safe to ignore a rule which has been installed by an user, and JS is Turing-complete, so we have no way to tell whether a <i>particular</i> rule is safe to ignore either.</div><div><br></div><div>So, given an existing installed system which uses JS rules, we can:</div><div><ul><li>(Replace unmodified JS rules installed by a RPM or similar package by updating to a new version of the RPM which drops the JS file and uses the replacement format. Does not help with unpackaged software and private configuration.)<br></li><li>(Have <i>some</i> crazy heuristics to parse JS code and try to convert it into equivalent rules in the new format. Very fragile, may work some of the time, but is not sufficient in general.)</li><li>Just ignore the JS rules, potentially allowing something the user disabled and needs to keep disabled. Absolutely unacceptable.</li><li>If we see any JS rule, close down polkit <i>completely</i> and reject any action by any user, or at best reject any action not done by UID 0. That pretty much kills the machine.</li></ul></div><div>So, AFAICT, for better or worse, distributions which already ship the JS backend are doomed to stay on that backend, unless they are willing to endure a <i>horribly</i> painful flag day. (Shipping two backends “for a while” does not help because for all that time the JS rules will stay working, not motivating the users to change, and when the JS rules are finally dropped, there is a single flag day.)</div><div><br></div><div><br></div><div>Of course, new distributions, or constrained projects where all users of polkit are known and can be converted, are not bound by this and could benefit from replacing the JS backend. I’m not sure that long-term bifurcating the ecosystem that way is worth it, though with the existing Debian split we may already be there. But with Debian staying at .pkla, maybe the natural other format is .pkla and not something entirely new.</div><div>    Mirek</div></div></div></div>