Replacing polkit JS backend

[Miloslav Trmac]

Hello,
2017-10-21 20:54 GMT+02:00 Ikey Doherty <ikey at solus-project.com>:

> On 21/10/17 19:39, Michael Biebl wrote:
> So to use the libvirt example:
>
> polkit.addRule(function(action, subject) {
>     if (action.id == "org.libvirt.api.connect.getattr" &&
>         subject.user == "berrange") {
>           if (action.lookup("connect_driver") == 'QEMU') {
>             return polkit.Result.YES;
>           } else {
>             return polkit.Result.NO;
>           }
>     }
> });
>
>
> You'd express that as follows (when all is complete)
>
> [Policy]
> Rules=libvirt.custom.rules
>
> [libvirt.custom.rules]
> Actions=org.libvirt.api.connect.getattr
> InUnixUsers=berrange
> ExpectedKeys=connect_driver
> ExpectedValues=QEMU
> Result=yes
> ResultInverse=no
>
> The idea was to avoid PKLAs use of "ResultActive" "ResultInactive"
> stanzas, and instead make each rule condition based with a given
> outcome. Rules can be layered with various conditions to handle
> other cases too. Just dupe the rule and alter the conditions
>
>
> >
> > That said, I'd be happy if this new keyfiles format would be something
> > other distros (most notably Fedora/Redhat/openSUSE) could agree on. At
> > least from the Debian side (and I assume by that extension Ubuntu)
> > there definitely would be interest in having a common format again
> > which is used by everyone and not as limited as the old pkla format.
> >
> > Regards,
> > Michael
> >
>
> Aye, don't wanna repeat history, hence this new approach. Would also be
> fantastic for upstream projects if they knew they could benefit from a
> unified polkit format. (Another example being gvfs referencing 'wheel'
> group which doesn't exist on all distros, hence the introduction of the
> special '%wheel%' substitution)
>

See one of the other mails, I’m worried that with the vaguely systemd-like
”no programming language, but a few ‘simple’ special-cased condition
operators” systems never stay simple. It’s easy and attractive to keep
extending them with more and more Condition* operators which will be
difficult to consume by any automated analysis, and potentially by users
(e.g. in the above example, can "ExpectedKeys" and "ExpectedValues" have
multiple values if they are plural? What is the separator? What is the
escaping mechanism for including the separator inside the values? What is
the semantics of N keys with M values?).

I view the centralized "send all data about the operation to a central
daemon, and have a central generalized mechanism to make a decision" model
as a mistake from the start. It seems much more natural to me if "the qemu
driver object in libvirt, read access" conceptually had a dumb ACL
attached. (That ACL could still be centrally stored, or at least centrally
enumeratable, if that seemed like a valuable property to someone; I don’t
see a strong case for it so far.)

Not that I know how to get from polkit to that ACL model…
    Mirek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/polkit-devel/attachments/20180103/f9396ad1/attachment.html>