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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
