sysusers.sh fails in empty chroot

[pmatilai]

Describe the bug

sysusers.sh fails when installing to an empty chroot

To Reproduce
Steps to reproduce the behavior on Fedora >= 39:

1. mkdir -p /srv/f41 && cd /srv/f41
2. dnf --disablerepo="*" --enablerepo="rawhide" --installroot=/srv/test download --resolve httpd
3. make sure %__systemd_sysusers is enabled and set to the rpm sysusers.sh script
4. rpm -Uv --root /srv/test --noscripts --noplugins *.rpm

Expected behavior
Some errors on filesystem installation expected due to --noscripts, but otherwise users and groups should get created and files assigned accordingly in the chroot.

Output

Verifying packages...
Preparing packages...
libgcc-14.1.1-6.fc41.x86_64
pcre2-syntax-10.43-2.fc41.1.noarch
ncurses-base-6.4-12.20240127.fc40.noarch
mailcap-2.1.54-5.fc40.noarch
fedora-release-identity-basic-41-0.14.noarch
fedora-repos-rawhide-41-0.2.noarch
fedora-gpg-keys-41-0.2.noarch
fedora-repos-41-0.2.noarch
fedora-release-common-41-0.14.noarch
fedora-release-41-0.14.noarch
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
groupadd: failure while writing changes to /etc/group
useradd: group '4' does not exist
useradd: group '1' does not exist
useradd: group '2' does not exist
useradd: group '50' does not exist
useradd: group '100' does not exist
useradd: group '0' does not exist
useradd: group '7' does not exist
useradd: group '12' does not exist
useradd: group '65534' does not exist
useradd: group '0' does not exist
useradd: group '0' does not exist
useradd: group '0' does not exist
useradd: group '0' does not exist
setup-2.15.0-4.fc41.noarch
[...]

Environment

• OS / Distribution: Fedora >= 39
• Version: rpm >= 4.19

Additional context
Using actual systemd-sysusers binary as %__systemd_sysusers, the only failure is from filesystem /lib64 due to --noscripts. --noscripts being necessary here to force the sysusers mechanism to be used rather than useradd scripts from packages.

[ffesti]

OK, digging through the shadow utils source code it looks like it is the SELinux handling that fails - without any SELinux failures being recorded. Creating /sys/fs/selinux/enforce in the chroot with a 0 in it make the code pass as it is content with SELinux being in permissive mode - well even just being ostensibly in permissive mode.

[pmatilai]

Oh, right. useradd/groupadd are confined utilities and their selinux policy will almost certainly need updating to work with all this - if the login.defs part works it'll fail on other items in turn, see #3227.

[pmatilai]

So perhaps the most useful line of investigation from here is to work with Fedora selinux-policy maintainer to see what needs to be done to support this.

[ffesti]

I don't think a updated SELinux policy will fix this. There are the parts of the strace that look relevant:

openat(AT_FDCWD, "/etc/selinux/config", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
futex(0x7f0dbd7441a0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/etc/selinux/targeted/contexts/files/file_contexts.subs_dist", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/selinux/targeted/contexts/files/file_contexts.subs", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/etc/selinux/targeted/contexts/files/file_contexts", 0x7ffd199e22f8, 0) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/etc/selinux/targeted/contexts/files/file_contexts.bin", 0x7ffd199e2390, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/sys/fs/selinux/enforce", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(5, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
umask(0777)                             = 022
openat(AT_FDCWD, "/etc/group-", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 6
umask(022)                              = 0777
fchown(6, 0, 0)                         = 0
fchmod(6, 0644)                         = 0
lseek(5, 0, SEEK_SET)                   = 0
read(5, "", 4096)                       = 0
fsync(6)                                = 0
close(6)                                = 0
utimensat(AT_FDCWD, "/etc/group-", [{tv_sec=1723101490, tv_nsec=0} /* 2024-08-08T09:18:10+0200 */, {tv_sec=1723101490, tv_nsec=0} /* 2024-08-08T09:18:10+0200 */], 0) = 0
close(5)                                = 0
futex(0x7f0dbd746500, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, "/proc/thread-self/attr/fscreate", O_RDWR|O_CLOEXEC) = -1 ENOENT (No such file or directory)
gettid()                                = 3653716
openat(AT_FDCWD, "/proc/self/task/3653716/attr/fscreate", O_RDWR|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/sys/fs/selinux/enforce", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
...
write(2, "groupadd: failure while writing "..., 54groupadd: failure while writing changes to /etc/group
) = 54

The error message comes from close_files() which dives down into commonio_close().

That calls in set_selinux_file_context() and reset_selinux_file_context().

These fail in libselinux because the config and /sys/ files it tries to access above are not to be found. Creating /sys/fs/selinux/enforce in the chroot with a 0 tricks groupadd into thinking selinux is not enforcing and though ignores those errors.

So I think the issue is not the selinux policy for the shadow utils but the fact that they try to make SELinux work in the chroot even if there are no SELinux config file and no /sys/ FS to be found.

[pmatilai]

As it happens, there's a shadow-utils ticket on this: shadow-maint/shadow#940
Filed by our friends at the mock camp even...

[pmatilai]

AFAICS the only way we could work around this in sysusers.sh is creating /sys/fs/selinux/enforce in the chroot if it doesn't exist, but that's just too gross of a hack because /sys is not even a regular filesystem but exporting runtime kernel info via sysfs(5).

Dropping this out of 4.20 milestone and adding info label because this is outside our direct control,