Bug 80921

Created attachment 102279 [details] [review]
0001-Don-t-prohibit-applications-from-including-authoriza.patch

I'm not sure removing this is a good idea and I think e.g. gnome-initial-setup is just busted or trying to do something wrong. I don't have a working Fedora system right in front of me - can you please post one of these files, for example the one from gnome-initial-setup? Thanks!

gnome-initial-setup ships this rule:

polkit.addRule(function(action, subject) {
    if (subject.user !== 'gnome-initial-setup')
        return undefined;

    var actionMatches = (action.id === 'org.freedesktop.udisks2.filesystem-mount-system' ||
                         action.id.indexOf('org.freedesktop.hostname1.') === 0 ||
                         action.id.indexOf('org.freedesktop.locale1.') === 0 ||
                         action.id.indexOf('org.freedesktop.accounts.') === 0 ||
                         action.id.indexOf('org.freedesktop.timedate1.') === 0 ||
                         action.id.indexOf('org.freedesktop.realmd.') === 0 ||
                         action.id.indexOf('org.freedesktop.RealtimeKit1.') === 0);

    if (actionMatches) {
        if (subject.local)
            return 'yes';
        else
            return 'auth_admin';
    }

    return undefined;
});


gnome-control-center uses this rule:

polkit.addRule(function(action, subject) {
	if ((action.id == "org.freedesktop.locale1.set-locale" ||
	     action.id == "org.freedesktop.locale1.set-keyboard" ||
	     action.id == "org.freedesktop.hostname1.set-static-hostname" ||
	     action.id == "org.freedesktop.hostname1.set-hostname" ||
	     action.id == "org.gnome.controlcenter.datetime.configure") &&
	    subject.local &&
	    subject.active &&
	    subject.isInGroup ("wheel")) {
		    return polkit.Result.YES;
	    }
});

We're considering adding the following rule to ABRT:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.problems.getall" &&
        subject.active == true &&
        subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }
});

These last two are to express the rule "unprivileged users must authenticate but admin users need not authenticate." It would be nice to have less-cumbersome syntax for this, and a way to figure out if the subject is in the configured polkit admin group without assuming (often incorrectly) that it's wheel.

Colin, what do you think?

Some more. Note that most of these use "wheel" and will be broken on Debian/Ubuntu.


50-libvirt.rules:

// Allow any user in the 'libvirt' group to connect to system libvirtd
// without entering a password.

polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.isInGroup("libvirt")) {
        return polkit.Result.YES;
    }
});


org.freedesktop.fwupd.rules:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.fwupd.update-internal" &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }
});


org.freedesktop.packagekit.rules:

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.packagekit.package-install" &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }
});

Arguably most of the "wheel" rules should be a native functionality of polkit, if that security model is what we have settled on; though no idea if/when that would happen.

The initial-setup example is, to me, the governing example.

A reasonable philosophy is that permission models should be simple and automated, and the intelligence should be in applications; in such a case the various services should already know about initial-setup and use a different action for this caller (so which would be simply allowed in polkit), or perhaps user:initial-setup should be considered an authenticated administrator (and the default auth_admin would apply).

Another reasonable philosopy is that applications should be simple, and the permission model should be programmable; that leads to the gnome-initial-setup JS rule shipped in the package.

I am personally more in favor of the first one (complex applications, simple permission models), but the JS polkit is inherently implyting the second philosophy, so allowing applications to ship programmable rules seems to be an unavoidable consequence.

Most of these rules could be handled by some extension to the current pkla files. E.g. in addition to allowing yes, no, auth-admin, auth-admin-keep, there could be a simple "admin" rule that allows the action without password for admin users, and otherwise functions as auth-admin.

gnome-initial-setup is really the exception here, in that it depends on the username.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/polkit/polkit/issues/52.