Replacing polkit JS backend

Sat Oct 21 19:12:01 UTC 2017

On 21/10/17 20:06, Jasper St. Pierre wrote:
> 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

Got you covered. I'm using two rules here because the linked rules
explicitly want to have the user matched, so its not just a simple
inverse - but its still trivial to convert.

[Policy]
Rules=gnome-initial-setup-local.rules; gnome-initial-setup.rules

[gnome-initial-setup-local.rules]
Actions=org.freedesktop.udisks2.filesystem-mount-system
ActionContains=org.freedesktop.hostname1.;
org.freedesktop.NetworkManager.; org.freedesktop.locale1.;
org.freedesktop.packagekit.system-sources-configure;
org.freedesktop.accounts.; org.freedesktop.timedate1.;
org.freedesktop.realmd.; org.freedesktop.RealtimeKit1.;
SubjectLocal=true
InUnixUsers=gnome-initial-setup
Result=yes

[gnome-initial-setup.rules]
Actions=org.freedesktop.udisks2.filesystem-mount-system
ActionContains=org.freedesktop.hostname1.;
org.freedesktop.NetworkManager.; org.freedesktop.locale1.;
org.freedesktop.packagekit.system-sources-configure;
org.freedesktop.accounts.; org.freedesktop.timedate1.;
org.freedesktop.realmd.; org.freedesktop.RealtimeKit1.;
SubjectLocal=false
InUnixUsers=gnome-initial-setup
Result=auth_admin

> 
> On Sat, Oct 21, 2017 at 11:54 AM, Ikey Doherty <ikey at solus-project.com
> <mailto: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 <mailto: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 <http://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 <http://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
>     <mailto:polkit-devel at lists.freedesktop.org>
>     https://lists.freedesktop.org/mailman/listinfo/polkit-devel
>     <https://lists.freedesktop.org/mailman/listinfo/polkit-devel>
> 
> 
> 
> 
> -- 
>   Jasper