Rework local authority configuration
@david
Submitted by David Zeuthen Assigned to David Zeuthen @david
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.