Based on https://bugzilla.redhat.com/show_bug.cgi?id=956005: The polkit manual states this: "Authorization rules are intended for two specific audiences System Administrators Special-purpose Operating Systems / Environments and those audiences only. In particular, applications, mechanisms and general-purpose operating systems must never include any authorization rules." However, it’s become clear that the .action mechanism is not sufficient for expressing various real-world situations (look in /usr/share/polkit-1/rules.d/ ; e.g. gnome-initial-setup and lightdm needs extra access for their special-purpose users, or allowing access to “wheel” members without a password,). Extending the .action mechanism, or inventing yet another one, purely to keep some abstract separation between users’ and programmers’ policy, is not reasonable; so just remove the documentation discouraging applications from adding their own .rules. (I can’t see an any obvious middle ground between just prohibiting it, and just allowing it: in particular, allowing applications to only drop in .rules for _their own_ actions isn’t sufficient, see gnome-initial-setup above for a counterexample.)
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.