On Sat, May 10, 2025 at 12:58:58PM -0000, Alex Haydock wrote: > Fedora Atomic bug documented here: https://bugzilla.redhat.com/show_bug.cgi?id=2359764 > > I think this bug comes from the systemtap .spec's use of traditional (non sysusers.d) methods to handle user creation. I tried to author a PR to solve this issue in the Fedora package repo: https://src.fedoraproject.org/rpms/systemtap/pull-request/32 > > After submitting the PR, I was informed that a prior PR had already solved this issue: https://src.fedoraproject.org/rpms/systemtap/pull-request/31 > > That prior PR made it into this recent release, which is now available in F42 as of a few days ago: https://bodhi.fedoraproject.org/updates/FEDORA-2025-fb27254eca > > Unfortunately, this hasn't fixed the issue for me. So I'm looking again at the spec (maintained upstream) to try and work out what might still be the problem and possibly re-factor my PR to properly solve the issue. > > I might be completely missing something, but the conditional branching logic introduced by the PR above (f892ad26592f97d32984ae088634e82c3c973138) seems to be backwards. From what I can tell, the branching conditional logic is actually checking for any version of Fedora *below* 42 and runs the updated sysusers.d logic if that check matches. This seems to be the opposite of the intended logic, as newer Fedora versions should use the newer sysusers.d logic. Hi, The logic is a bit confusing, but it doesn't seem to be wrong :] In F42+, rpm takes care of creating system users: - the package contains a sysusers.d file: $ rpm -ql systemtap-runtime | rg sysusers /usr/lib/sysusers.d/systemtap-runtime.conf) - when the pacakge is built, this is turned into metadata on the package: $ rpm -qP systemtap-runtime | rg 'user|group' group(stapdev) = ZyBzdGFwZGV2IDE1OAAA group(stapsys) = ZyBzdGFwc3lzIDE1NwAA group(stapunpriv) group(stapunpriv) = ZyBzdGFwdW5wcml2IDE1OQAA group(stapusr) = ZyBzdGFwdXNyIDE1NgAA groupmember(stapunpriv/stapunpriv) = bSBzdGFwdW5wcml2IHN0YXB1bnByaXYA user(stapunpriv) = dSBzdGFwdW5wcml2IDE1OSAic3lzdGVtdGFwIHVucHJpdmlsZWdlZCB1c2VyIiAvdmFyL2xpYi9zdGFwdW5wcml2IC9zYmluL25vbG9naW4A or $ rpm -q --qf='[%{SYSUSERS}\n]' systemtap-runtime g stapdev 158 g stapsys 157 g stapunpriv 159 g stapusr 156 m stapunpriv stapunpriv u stapunpriv 159 "systemtap unprivileged user" /var/lib/stapunpriv /sbin/nologin - when this package is installed, rpm calls systemd-sysusers to create the users based on the metadata: $ dnf install systemtap-runtime ... [3/4] Installing dyninst-0:13.0.0-5.fc42.x86_64 100% | 31.4 MiB/s | 14.2 MiB | 00m00s >>> Running sysusers scriptlet: systemtap-runtime-0:5.3-1.fc42.x86_64 >>> Finished sysusers scriptlet: systemtap-runtime-0:5.3-1.fc42.x86_64 >>> Scriptlet output: >>> Creating group 'stapdev' with GID 158. >>> Creating group 'stapsys' with GID 157. >>> Creating group 'stapunpriv' with GID 159. >>> Creating group 'stapusr' with GID 156. >>> Creating user 'stapunpriv' (systemtap unprivileged user) with UID 159 and GID 159. >>> [4/4] Installing systemtap-runtime-0:5.3-1.fc42.x86_64 100% | 1.4 MiB/s | 1.0 MiB | 00m01s Note that the users and groups are create *before* the package itself is unpacked. In F42-, this creation would need to be handled by a scriptlet in the package. That is why the logic is how it is: we don't need the scriptlet in newer versions. The above was about "traditional" package-based systems. On an rpm-ostree system, the implementation is different, but it is supposed to provide the same result. The issue is probably somewhere in that tooling. The sysusers.d file looks like this: $ cat /usr/lib/sysusers.d/systemtap-runtime.conf g stapusr 156 g stapsys 157 g stapdev 158 g stapunpriv 159 u stapunpriv 159 "systemtap unprivileged user" /var/lib/stapunpriv /sbin/nologin m stapunpriv stapunpriv A lot of this is redundant. The following would be enough: g stapusr 156 g stapsys 157 g stapdev 158 u stapunpriv 159 "systemtap unprivileged user" /var/lib/stapunpriv But the redundancy should not cause a problem. I think we need to ask some rpm-ostree folks to look into this. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
