Polkit on Duktape

[Miloslav Trmac]

2015-08-13 20:12 GMT+02:00 Matthew Miller <mattdm at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/polkit-devel/attachments/20150813/08f14e15/attachment.html>