SELinux prevents login (Process /usr/lib/systemd/systemd could not be executed)

After an successfully upgrade to f36 I observed some strange selinux error messages. So I tried to solve this with restorecon and touch /.autorelabel ; reboot :open_mouth: Bad idea :open_mouth:
Problem After a correct attempt to login (Gui), the the system asks immediately again for the login. With a wrong pw, the system asks for the correct pw.
Trying to boot the rescue system, the boot process fails. It can’t perform a ‘sulogin’
First diagnostics With some support in an other thread I was able to detect that my problem is related to selinux.
Ugly workaround Starting the system with the kernel parameter selinux=0 it is possible to login and useing the system like normal. But this is no solution, or?
Question
Since a cleanup with dnf reinstall systemd, dnf reinstall selinux-policy.noarch and touch /.autorelabel; reboot didn’t helped, I’m looking for new ideas/hints.
Logs Inspecting (journalctl -p 3 -x --boot=-1) the last boot (activated selinux) I found:

Mai 25 11:15:41 localhost.localdomain gdm-password][1859]: gkr-pam: unable to locate daemon control file
Mai 25 11:15:41 localhost.localdomain systemd[1869]: user@1000.service: Failed to execute /usr/lib/systemd/systemd: Permission denied
Mai 25 11:15:41 localhost.localdomain systemd[1869]: user@1000.service: Failed at step EXEC spawning /usr/lib/systemd/systemd: Permission denied
░░ Subject: Process /usr/lib/systemd/systemd could not be executed
░░ Defined-By: systemd
░░ Support: …
░░
░░ The process /usr/lib/systemd/systemd could not be executed and failed.
░░
░░ The error number returned by this process is ERRNO.
Mai 25 11:15:41 localhost.localdomain systemd[1]: Failed to start user@1000.service - User Manager for UID 1000.
░░ Subject: A start job for unit user@1000.service has failed
░░ Defined-By: systemd
░░ Support: …
░░
░░ A start job for unit user@1000.service has finished with a failure.
░░
░░ The job identifier is 3037 and the job result is failed.
Mai 25 11:15:41 localhost.localdomain gdm-password][1872]: gkr-pam: couldn’t run gnome-keyring-daemon: Keine Berechtigung
Mai 25 11:15:41 localhost.localdomain gdm-password][1859]: gkr-pam: gnome-keyring-daemon didn’t start properly

Also I found (journalctl | grep autorelabel)some comments to autorelable:

Mai 25 11:14:39 localhost.localdomain selinux-autorelabel[1208]: Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/200/snappy/cil:302
Mai 25 11:14:39 localhost.localdomain selinux-autorelabel[1208]: Failed to resolve AST
Mai 25 11:14:39 localhost.localdomain selinux-autorelabel[1208]: genhomedircon: Failed!
Mai 25 11:14:39 localhost.localdomain selinux-autorelabel[827]: Relabeling / /boot /dev /dev/hugepages /dev/mqueue /dev/pts /dev/shm /home /run /store /sys /sys/fs/cgroup /sys/fs/pstore /sys/kernel/debug /sys/kernel/tracing /tmp
Mai 25 11:14:39 localhost.localdomain selinux-autorelabel[1211]: /sbin/setfiles: /etc/selinux/targeted/contexts/files/file_contexts.bin: context system_u:object_r:container_runtime_exec_t:s0 is invalid
Mai 25 11:14:39 localhost.localdomain selinux-autorelabel[1211]: /sbin/setfiles: /etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin: context unconfined_u:object_r:snappy_home_t:s0 is invalid
Mai 25 11:14:50 localhost.localdomain selinux-autorelabel[1211]: /sbin/setfiles: conflicting specifications for /usr/bin/uic-qt5 and /usr/lib64/qt5/bin/uic, using system_u:object_r:lib_t:s0.
Mai 25 11:14:50 localhost.localdomain selinux-autorelabel[1211]: /sbin/setfiles: conflicting specifications for /usr/bin/qlalr and /usr/lib64/qt5/bin/qlalr, using system_u:object_r:lib_t:s0.

Mai 25 11:15:10 localhost.localdomain selinux-autorelabel[827]: Cleaning up labels on /tmp
Mai 25 11:15:10 localhost.localdomain selinux-autorelabel[1235]: ERROR: src/skipcpio/skipcpio.c:91:main(): Cannot open file ‘/boot/1767bcd731864042b60a97dfd5130265/5.17.9-300.fc36.x86_64/initrd’
Mai 25 11:15:10 localhost.localdomain selinux-autorelabel[1236]: cpio: Vorzeitiges Ende des Archivs
Mai 25 11:15:10 localhost.localdomain selinux-autorelabel[1237]: ERROR: src/skipcpio/skipcpio.c:91:main(): Cannot open file ‘/boot/1767bcd731864042b60a97dfd5130265/5.17.9-300.fc36.x86_64/initrd’

Any help apreciated
Uwe

I encountered almost the same problem as you. Following this post reply, I tried running sudo restorecon -rv / instead of touch /.autorelabel; reboot and I also set SELinux policy to permissive. After doing these two things I don’t see SELinux warnings on systemd itself anymore, though there are still other unwanted SELinux warnings, and my system is able to login (possibly due to the permissive policy). Hope this will help.

Initially I’ve done both resorecon and .autorelable. Now I tried only restorecon -rv /. The result is a bit different but at the end the same. With deactivates selinux I can login, w/o I cant even get a login prompt. The system(GUI) seems to hang just before presenting the list of users.
Perhaps starting the kernel with selinux, but set policy to permissive (/etc/selinux/config) might bring me closer to your situation, but it doesn’t seem like a solution.

… it works :smiley:
I had tried the workaround from SELinux-related errors … once before, but with no effect.
Quite desperately, I tried it today again. This time I recognized that dnf reinstall selinux-policy-targeted swtpm snapd-selinux flatpak-selinux container-selinux osbuild-selinux had complained about some uninstalled packages.
Namely:

  • snapd-selinux Wasn’t installed before, but was mentioned ind the error logs Failed to resolve allow statement at /var/lib/selinux/targeted/tmp/modules/200/snappy/cil:302
  • selinux-policy-targeted couldn’t be reinsalled, because the installed f36-version couldn’t be found on ‘update’.

After the ‘installing’ the missed packages, I was able to do the workaround properly and to reboot into a system with SELinux.
Now I was even able to find duplicate packages and to clean them up. Before the workaround dnf check couldn’t find any duplicates.

Thanx to all.

1 Like

Thanks for the tip, @uwereh . I fixed the Workarounds section in https://discussion.fedoraproject.org/t/selinux-related-errors-when-updating-packages-or-using-certain-tools-after-upgrade-to-fedora-36/73562 to first ask people to use dnf distrosync and only then dnf reinstall. I didn’t realize that dnf reinstall requires exact package versions to be present in the repo. With the fixed approach, it should hopefully work for everyone.