sysusers.sh fails with enforcing SELinux

[pmatilai]

Tested on Fedora 39 with rpm from git master:

# rm -rf /srv/test/;dnf -y --installroot=/srv/test --disablerepo="*" --enablerepo="rawhide" install setup
[...]
Running transaction
  Running scriptlet: filesystem-3.18-23.fc41.x86_64                         1/1 
  Preparing        :                                                        1/1 
  Installing       : fedora-release-identity-basic-41-0.17.noarch           1/8 
  Installing       : fedora-repos-rawhide-41-0.2.noarch                     2/8 
  Installing       : fedora-gpg-keys-41-0.2.noarch                          3/8 
  Installing       : fedora-repos-41-0.2.noarch                             4/8 
  Installing       : fedora-release-common-41-0.17.noarch                   5/8 
  Installing       : fedora-release-41-0.17.noarch                          6/8 
  Running scriptlet: setup-2.15.0-5.fc41.noarch                             7/8 
groupadd: unable to chroot to directory /srv/test/: Operation not permitted
groupadd: unable to chroot to directory /srv/test/: Operation not permitted
[...]
useradd: group '4' does not exist
useradd: group '1' does not exist
useradd: group '2' does not exist
useradd: group '50' does not exist
[...]

This is specific to the sysusers.sh script as using native systemd-sysusers does work even if SELinux is enabled.
I think this has to do with useradd/groupadd having their own confined policies under SELinux whereas systemd-sysusers is not, and so it'll need fixing in the selinux-policy rather than the script, just filing this here for information and as a reminder to file it on Fedora side.

[ffesti]

This looks very much like a duplicate of #3186. Or is there anything that makes this distinct?

[pmatilai]

#3186 was filed with the assumption that it's the empty chroot that is the problem and requires some changes to the script, whereas this is about SELinux. If #3186 is also really all about SELinux then we should close that in favor of this (and, work with selinux-policy maintainer to sort it)

[ffesti]

OK, this is weird. The test case in #3186 succeeds in chrooting and then fails due to the empty chroot. Here we fail a step earlier. I wonder if dnf is not running the in same SELinunx context than RPM.

[pmatilai]

Oh... the #3186 reproducer is with --noplugins, which means selinux context doesn't get set for files or scriptlet execution. Not sure what was my intention there, maybe it was even intentional to differentiate from SELinux issues, allegedly, but it's clearly more complicated than that.

[pmatilai]

So, I don't really know if there are one, two or even more individual bugs in here. Lotsa moving parts for sure.

I'm almost positive that selinux-policy will need tweaks to accommodate for the chroot usage we now do from the outside, but whether there are other things we need to do on our side I dunno.

Maybe we should simply have a "just make it work" ticket 😄 (testing with mock and all that)

[ffesti]

Yup. The case above sets the chroot dir to

dr-xr-xr-x. 18 root root system_u:object_r:root_t:s0 4096 Aug  8 10:47 ../test

while without the selinux plugin it is

dr-xr-xr-x. 11 root root unconfined_u:object_r:var_t:s0 4096 Aug  8 10:50 ../test

[pmatilai]

Yup, and without the plugin, scriptlets will run in a different context which will probably affect some domain transitions (or stuff) in the policy.

[ffesti]

Looks like useradd has sys_chroot capability and and groupadd just hasn't. Weird...

[pmatilai]

Oh, nice digging. I had this nagging feeling that there's something odd about these errors, but that's it: user additions succeed, its just groups that fail. And, that explains a lot.

[pmatilai]

So yep, this will need to be addressed in selinux-policy. The missing chroot capability in groupadd policy is seems like a simple oversight, it's not as if the chroot operation is the most common thing...
This ticket is just a reminder for us to do that.

[pmatilai]

Submitted a PR: fedora-selinux/selinux-policy#2316

[pmatilai]

Okay that got merged pretty swiftly, closing this.