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 <i...@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 <mat...@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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/polkit-devel > -- Jasper
_______________________________________________ polkit-devel mailing list polkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/polkit-devel