Replacing polkit JS backend

[Jasper St. Pierre]

One more example for you, from gnome-initial-setup [0]. To give context on
this scenario, gnome-initial-setup is acting as if it was the administrator
in a restricted environment, guiding you through setting up your system, so
it asserts authorization over its own actions. A fairly flexible whitelist
of actions is used to sanity check that they're in the ballpark, but that's
just an insurance policy.

I notice that Debian actually patches this to add an additional rule to the
JavaScript -- is Debian shipping JS-based rules or not?

[0]
https://git.gnome.org/browse/gnome-initial-setup/tree/data/20-gnome-initial-setup.rules
[1]
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/gnome-initial-setup/debian/patches/polkit-allow-NM.patch?view=markup&pathrev=51145

On Sat, Oct 21, 2017 at 11:54 AM, Ikey Doherty <ikey at solus-project.com>
wrote:

> Reply is down thar ->
>
> On 21/10/17 19:39, Michael Biebl wrote:
> > Hi!
> >
> >
> > 2017-10-21 19:28 GMT+02:00 Matthew Miller <mattdm at mattdm.org>:
> >> On Sat, Oct 21, 2017 at 03:40:40AM +0100, Ikey Doherty wrote:
> >>> I've opted to make it an **alternative** backend to ease migration,
> >>> thus:
> >>>
> >>>  --with-backend=js|keyfile
> >>
> >> Nice. I'm personally super in favor of it. Not speaking for Red Hat
> >> officially, by any means. From a pure Fedora point of view...
> >> I don't think we have many users taking advantage of the javascript
> >> format, but if there are, I would prefer to not break them.
> >
> > I'm very interested in this. I personally was never a huge fan of the
> > JS based polkit version. mozjs is just a huge PITA.
> > Martin Pitt, as co-maintainer of polkit in Debian, even less so, which
> > is why all Debian and Ubuntu derived distros currently still use
> > policykit 105 (+ a huge load of backported fixes).
> >
> > So far, we didn't have many users which came to us asking for the
> > additional flexibility provided by the js-based rules.
> > The notable exception is the Debian postgresql maintainer who wanted
> > to use the the more granular polkit filtering that systemd allows.
> > See the PR Jasper mentioned.
> >
> > Can something like this be expressed in the new keyfile format (at
> > least to some extent)?
>
> 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)
>
> - ikey
> _______________________________________________
> polkit-devel mailing list
> polkit-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/polkit-devel/attachments/20171021/1b9c3005/attachment-0001.html>