The "polkit" package is currently shipping several files and directories which are owned by the "polkitd" user/group, for example: ``` $ stat /usr/share/polkit-1/rules.d File: /usr/share/polkit-1/rules.d Size: 62 Blocks: 0 IO Block: 4096 directory Access: (0700/drwx------) Uid: ( 999/ polkitd) Gid: ( 0/ root) ``` However the specfile does create the "polkitd" user and group with dynamic IDs at install time: ``` %pre getent group polkitd >/dev/null || groupadd -r polkitd getent passwd polkitd >/dev/null || useradd -r -g polkitd -d / -s /sbin/nologin -c "User for polkitd" polkitd exit 0 ``` This means that across different installs/composes the numeric UID/GID of the files may vary arbitrarily (in the example above it got "999"). This poses a problem from the point of view of OS content reproducibility. It also causes issues to systems doing out-of-band composes (e.g. ostree or other image-based technologies). For these reasons, it would be better to get a static UID and GID allocated for the "polkitd" user/group in Fedora.
As I didn't hear any positive/negative feedback here, I went ahead and formally brought this to the attention of FPC with a static UID/GID request as described in https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_soft_static_allocation. The static UID/GID request ticket for the "polkitd" user/group is at https://pagure.io/packaging-committee/issue/1189.
As said at the packaging-commitee, it would be more proper to incorporate systemd-sysusers [1] (planned in/after upcoming rebase to polkit-121) instead of hardcoding a specific UID/GID, which itself is not robust enough. This has been long-discussed in upstream. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2095453
The two things are not directly entangled. The tickets are neither duplicate nor related, so it would be good to re-open and keep iterating on this one in parallel. The `polkit` package can switch to sysusers.d fragments at any point, either with dynamic or static UID/GID, regardless of this ticket (we already have such cases in other Fedora packages). The problem here is with directories/files shipped as part of the package and owned by a custom user/group, for example the following: ``` d00750 0 999 /etc/polkit-1/localauthority d00700 999 0 /etc/polkit-1/rules.d d00700 999 0 /usr/share/polkit-1/rules.d ``` Those do get arbitrary non-deterministic UID/GID ownership on each different system doing composes/installs, which has some detrimental effects on reproducibility (and that we are trying to avoid/resolve here). For `/etc` entries that could be avoided through tmpfiles.d entries in order to create them via systemd-tmpfiles (I'd be happy with that alternative too, it requires a bit of packaging rework). For `/usr` entries I don't see much alternative right now. That directory is part of the (possibly immutable) OS content/image and its current ownership by a dynamic UID/GID is problematic (regardless of whether the creation is performed through useradd or systemd-sysusers). How did you envision addressing this (other than getting static IDs for it)? Could these perhaps be moved to a more relaxed `root:root` ownership and 0755 permissions without causing security troubles?
Re-opening as this is affecting all rpm-ostree based variants of Fedora and as Luca mentioned this is independent of the move to sysusers
Send PR.
Thanks for the feedback Jan, I'll then keep pushing forward the static ID request at https://pagure.io/packaging-committee/issue/1189. I'll ping back when a pair of UID/GID has been allocated.