2015-08-13 20:12 GMT+02:00 Matthew Miller <mat...@mattdm.org>: > On Thu, Aug 13, 2015 at 09:37:38AM -0700, Jasper St. Pierre wrote: > > Is that really different from standalone releases of mozjs, which have > > never been officially supported by Mozilla? > > Are people really using / area we getting a lot of value from the > javascript functionality at all? Is there any possiblity of going back > to a more... bounded configuration system? >
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 https://libvirt.org/aclpolkit.html . 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. 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 *might* be useful, and let the user write arbitrary JS as they wish. (I think this would be a *good* design limitation, but it *is* 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.) 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. (Of course, dropping JS would be breaking backward compatibility, which I *hate*. But that’s unavoidable in this subthread.) 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. Mirek
_______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/polkit-devel
