pkla-check-authorization is an internal helper program of pkla-polkit-compat. You shouldn't need to run it directly, except for debugging purposes.
The arguments to pkla-check-authorization are, in order:
Files with .pkla extension are read from all directories located inside the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories (or as specified using the --paths option). By default, the following sub-directories are installed.
/etc/polkit-1/ `-- localauthority |-- 10-vendor.d |-- 20-org.d |-- 30-site.d |-- 50-local.d `-- 90-mandatory.d
/var/lib/polkit-1/ `-- localauthority |-- 10-vendor.d |-- 20-org.d |-- 30-site.d |-- 50-local.d `-- 90-mandatory.d
The /etc/polkit-1/localauthority hierarchy is intended for local configuration and the /var/lib/polkit-1/localauthority is intended for 3rd party packages.
Each .pkla file contains one or more authorization entries. If the underlying filesystem supports file monitoring, the Local Authority will reload information whenever .pkla files are added, removed or changed.
Each directory is intended for a specific audience
and new directories can be added/removed as needed.
As to regards to the content, each .pkla file is a standard key file and contains key/value pairs in one or more groups with each group representing an authorization entry. A .pkla file MUST be named by using a scheme to ensure that the name is unique, e.g. reverse DNS notation or similar. For example, if the organization is "Acme Corp" needs to modify policy for the product "Frobnicator", a name like com.acme.frobnicator.pkla would be suitable.
Each group in a .pkla file must have a name that is unique within the file it belongs to. The following keys are recognized:
The authorization entries discussed above are consulted using the following algorithm.
The authorization entries from all .pkla files are ordered using the following rules. First all the basename of all sub-directories (e.g. 30-site.d) from both the /etc/polkit-1/localauthority and /var/lib/polkit-1/localauthority directories are enumerated and sorted (using the C locale). If a name exists in both /etc and /var, the one in /etc takes precedence. Then all .pkla files are read in order from this list of sub-directories. For each .pkla file, authorizations from each file are appended in order resulting in an ordered list of authorization entries.
For example, given the following files
/var/lib/polkit-1 └── localauthority ├── 10-vendor.d │ └── 10-desktop-policy.pkla ├── 20-org.d ├── 30-site.d ├── 50-local.d ├── 55-org.my.company.d │ └── 10-org.my.company.product.pkla └── 90-mandatory.d /etc/polkit-1 └── localauthority ├── 10-vendor.d │ └── 01-some-changes-from-a-subvendor.pkla ├── 20-org.d ├── 30-site.d ├── 50-local.d ├── 55-org.my.company.d │ └── 10-org.my.company.product.pkla └── 90-mandatory.d
the evaluation order of the .pkla files is:
When the list of authorization entries has been calculated, the authorization check can be made. First, the user of the Subject is determined and the groups that the user belongs are looked up.
Then, authorization entries that include the "default" field value in the Identity field are consulted in order. If the authorization entry matches the data from the authorization check, then the authorization result from RequireAny, RequireInactive or RequireActive is used.
Next, for each group identity, all authorization entries that contain a matching group entry are again consulted in the same manner.
Finally, the authorization entries are consulted using the user identity in the same manner.
The following .pkla file grants authorization to all users in the staff group for actions matching the glob com.example.awesomeproduct.* provided they are in an active session on the local console:
[Normal Staff Permissions] Identity=unix-group:staff Action=com.example.awesomeproduct.* ResultAny=no ResultInactive=no ResultActive=yes
If the users homer and grimes are member of the staff group but policy requires that an administrator needs to authenticate every time authorization for any action matching com.example.awesomeproduct.* is required, one would add
[Exclude Some Problematic Users] Identity=unix-user:homer;unix-user:grimes Action=com.example.awesomeproduct.* ResultAny=no ResultInactive=no ResultActive=auth_admin
and make sure this authorization entry is after the first one.
The following entry modifies the default authorization decision (it is overridden by any entry that matches using unix-user: or unix-group:, but overrides any defaults set by the application author in an .action file):
[Disable Access by Default] Identity=default Action=com.example.awesomeproduct.* ResultAny=no ResultInactive=no ResultActive=no