Open polkit-github-migration-bot opened 14 years ago
In gitlab.freedesktop.org by bugzilla-migration on Sep 14, 2010, 09:14
:speech_balloon: David Zeuthen @david
said:
Crazy idea: Maybe a better setup than .pkla files would be to do things exactly like udev does - with rules
ACTION=="org.libvirt.manage", USER=="davidz", RESULT="auth_admin"
ACTION=="org.libvirt.*", RUN="/path/to/script"
ACTION=="org.udisks.mount", ACTIVE=="true", LOCAL=="true", RESULT="yes"
So we'd have and
/etc/polkit-1/localauthority/rules.d/ /var/polkit-1/localauthority/rules.d/
(same way udev has /lib/udev/rules.d and /etc/udev/rules.d - we'd also include nice and useful semantics such as
Rule files are required to have a unique name, duplicate file names are
ignored. Files in /etc/udev/rules.d/ have precedence over files with
the same name in /lib/udev/rules.d/. This can be used to ignore a
default rules file if needed.
which is from the udev(8) man page.)
and, more importantly, this allows running scripts/programs to determine if the given Subject is authorized or not. Which basically makes the PolicyKit Local Authority backend 100% scriptable. Which I think is something most admins want.
In gitlab.freedesktop.org by bugzilla-migration on Feb 23, 2011, 14:06
:speech_balloon: David Zeuthen @david
said:
Repurposing this bug for reworking local authority configuration
In gitlab.freedesktop.org by bugzilla-migration on May 17, 2012, 23:25
:speech_balloon: David Zeuthen @david
said:
I created a new branch for an experiment, see
http://cgit.freedesktop.org/polkit/log/?h=wip/js-rule-files
that embeds a JS interpreter (running inside polkitd). The idea is that admins can drop .rules files in /etc/polkit-1/rules.d and these rules are JS scripts. This allows maximum flexibility while still allowing relatively simple files. A lot of information is available in the passed @subject value, for example pid, user-name, groups, session and seat. See below
With the rules file in [1], I get
00:12:40.780: /etc/polkit-1/rules.d/10-example.rules:8: action=org.freedesktop.policykit.exec 00:12:40.780: /etc/polkit-1/rules.d/10-example.rules:9: subject=[Subject pid=7449 seat=seat0 session=1 local=true active=true user=davidz groups=davidz,wheel] 00:12:40.780: /etc/polkit-1/rules.d/10-example.rules:11: now=Fri May 18 2012 00:12:40 GMT-0400 (EDT)
and if from another seat I get
00:11:29.680: /etc/polkit-1/rules.d/10-example.rules:8: action=org.freedesktop.policykit.exec 00:11:29.680: /etc/polkit-1/rules.d/10-example.rules:9: subject=[Subject pid=30980 seat= session=8 local=false active=true user=bateman groups=bateman] 00:11:29.680: /etc/polkit-1/rules.d/10-example.rules:11: now=Fri May 18 2012 00:11:29 GMT-0400 (EDT)
The only real missing feature is a polkit.spawn() method to run arbitrary helpers (which is of course very expensive so should be used sparingly).
[1] : /etc/polkit-1/rules.d/10-example.rules
/ -- mode: js; js-indent-level: 4; indent-tabs-mode: nil -- /
polkit.addAdministratorRule(function(action, subject) { return ["unix-group:sys", "unix-user:root"]; });
polkit.addAuthorizationRule(function(action, subject) { polkit.log("action=" + action); polkit.log("subject=" + subject); var now = new Date(); polkit.log("now=" + now); if (action == "org.freedesktop.policykit.exec" && subject.isInGroup("staff")) { return "yes"; } return null; });
In gitlab.freedesktop.org by yecril71pl1 on May 7, 2023, 22:47
Your real-world example does not work:
You are not authorized to access bug #544579.
In gitlab.freedesktop.org by bugzilla-migration on Sep 14, 2010, 08:42
Link to the original issue: https://gitlab.freedesktop.org/polkit/polkit/-/issues/12
Submitted by David Zeuthen
@david
Assigned to David Zeuthen
@david
Link to original bug (#30181)
Description
Consider the following .pkla files
/etc/polkit-1/localauthority/50-local.d/10-org.acme.pkla: [Allow group staff to do org.acme.frobnicate] Identity=unix-group:staff Action=org.acme.frobnicate ResultAny=yes ResultInactive=yes ResultActive=yes
and
/etc/polkit-1/localauthority/10-vendor.d/10-org.vendor.lockdown.pkla: [Lock org.acme.frobnicate down] Identity=unix-user:* Action=org.acme.frobnicate ResultAny=auth_admin ResultInactive=auth_admin ResultActive=auth_admin
where the former is provided by the 3rd party that provides the org.acme.frobnicate action (e.g. the software package) and the latter is provided by the OS vendor.
Because of the way .pkla files work, e.g.
First we run through .pkla files in order for Group identities that the Subject in question belongs to
Then we run through .pkla files in order for the User identity for the Subject in question
the latter always "win" even though the former has a higher priority. This is problematic because it's a semi-reasonable thing for the OS vendor to want to do.
One solution would be to allow "Identity=*" to mean any and then declare the order to be
First we run through .pkla files in order and apply any section where Identity=*
First we run through .pkla files in order for Group identities that the Subject in question belongs to
Then we run through .pkla files in order for the User identity for the Subject in question
This way OS vendors can "lock down" everything without interfering with other .pkla files.
Another option is to completely rethink how the Local Authority is configured and do something a lot simpler. This might not be too late as we haven't hit 1.0 yet.
See https://bugzilla.novell.com/show_bug.cgi?id=544579 for a real-world example of where an OS vendor runs into this problem.