This article nicely (and simply) explains the intention and functionality of Polkit.
-
Polkit 0.106 switched from the ".pkla (Policy Kit Local Authority / pklocalauthority)" file format to a JavaScript-based ".rules" configuration file format
See the original announcement and explanation for this change. See the fundamental differences between these two file formats in this simple example.
The comments at this page concisely reflect the year long debates this change triggered, including most of the technical and usablility issues denoted.
Note that there was no migration period (in which both file formats were supported): Polkit ≤ 0.105 solely understands ".pkla" files, while Polkit ≥ 0.106 only understands ".rules" files. -
Consequences / effects for Linux distributions
Aside of all usability issues (mainly JavaScript not being among the repertoire of an UNIX admin) and a programming languagage ("touring complete") being unsuitable and problematic to dangerous for configuration files (see sendmail.cf and some other (hi)stories), requiring a JavaScript interpreter as a fundamental depencendcy and needed early at the system start is the major technical issue: This Ubuntu bug summarises it well.
Consequently most Linux distributions stayed with Polkit 0.105 for a while and then started to take different approaches, often multiple of them temporally staggered:
- Backport fixes and even some new fuctionality from newer Polkit releases, creating Polkit 0.105-z versions.
- Create tools to automatically convert policy rules in the ".pkla" file format to the ".rules" file format.
- Extend the recent Polkit to parse ".pkla" files, e.g. by the polkit-pkla-compat helper.
- Rewrite all distribution specific policy rules as ".rules" files (by the help from tools denoted in point ii above) and completly switch to recent Polkit releases: Users of these distributions have to do the same for their own policy rules, then.
-
Polkit versions in SailfishOS
As with some other components, SailfishOS tends to lag behind recent Polkit releases, which is not neccesarily a bad thing.
SailfishOS 2.2.0 deployed Polkit 0.104, some later release (before SailfishOS 3.2.1) switched to Polkit 0.105 and SailfishOS 4.0.1 is still deploying Polkit 0.105.
This looks like aforementioned approach 1, although I have not checked which Polkit 0.105 variant the SailfishOS' version is based on or which backport patches it incorporates.
The Polkit documentation nicely provides older releases!
Thus assess per pkaction --version, which Polkit version you are running and use this documentation release, e.g. its 0.105 version.
Specifically this is the latest and last (original) documentation of pklocalauthority, i.e. the ".pkla" file format.
Nice examples with explanations for ".pkla" files:
- libvirt's SSHPolicyKitSetup
- Actually a report of a resolved Gentoo bug, but it also provides a nice example
Using pkaction:
pkaction(without any options) lists all action IDs, which Polkit controls.pkaction --verboselists the configuration of all action IDs.pkaction --verbose --action-id <action ID>lists the configuration of the action IDs selected (supports globbing per "*", needs quoting then).
crypto-sdcard deploys a single ".pkla" file in /etc/polkit-1/localauthority/50-local.d/69-cryptosd.pkla, which was significantly refactored and expanded in crypto-sdcard 1.7.0.
69-cryptosd.pkla (since v1.7.0) uniformly extends udisks2's default policy configuration depolyed by SailfishOS ≥ 2.2.0, which is comprised of udisks2's original configuration (e.g., for udisks 2.7.5, or from its documentation, e.g. for udisks 2.8.1) plus Jolla's patches (SailfishOS 2.2.x: 0003-Loosen-up-mount-unmount-rights.patch / SailfishOS ≥ "2.2.2" aka 3.0.0: 0003-Loosen-up-polkit-policies-to-work-from-another-seat.patch).
- Allow programs running in the root context (e.g., crypto-sdcard) to automatically unlock non-system crypto "containers" (if they can provide the necessary credentials).
- Carefully relax rules for some harmless actions (WRT SMART data, power saving etc.) to be programatically executed by the root or primary user on non-system devices.
Note that SMART suppport seems to be disabled in SailfishOS: Originally (2018-03-14 to 2021-10-22) per 0002-Drop-smartata-dependencies.patch, now per 0002-Make-libatasmart-support-optional.patch. - Alleviate some (IMO) overly careful asking (or call it "nagging with authorisations") by Polkit for some interactive actions for the primary user, plus a few additional ones for the root user.
- Allow "primary" SailfishOS users (i.e., in the
unix-group:systemfor at least SailfishOS 2.2.0 - 3.x.y (≥ 3.2.1), rsp. in theunix-group:media_rwfor SailfishOS ≥ 3.x.y (< 3.2.1)) to use the relaxed user rules: This usually affects only a single user (the "primary user"), either nemo or defaultuser. - Intentionally allow all users in the
unix-group:root(i.e., not just theunix-user:root) to use their relaxed rules.
While there is only a single user (root) in the group "root" on SailfishOS by default, this enables an admin to let additional user(s) use these relaxed rules by adding them to the "root" group as their secondary group.
Workflow
- Get hold of udisks2's policy rules as deployed by the oldest (still SailfishOS 2.2.0) and newest ("master", i.e. currently: SailfishOS 4.1.0) SailfishOS release to be supported by crypto-sdcard, either by copying them from SailfishOS installations, or by downloading the right udisks2 versions of the org.freedesktop.UDisks2.policy.in file (2.7.5 and 2.8.1) plus patching them with Jolla's patches.
Also look at the current version of the org.freedesktop.UDisks2.policy.in from udisks2's "master" branch, to anticipate future actions. - Manually compare these three files and decide which policies to alter, separately for the root user(s) and the primary user.
- Implement these altered policies in .pkla format, two separate files for
- ... the root user(s).
- ... the primary user.
- Merge these changes into a single file while grouping actions as appropiate: 69-cryptosd.pkla