Somehow, something broke my Linux desktop yesterday. Booted up early in the morning, everything worked fine. Downloaded some updates, browsed the web, and then rebooted. Post-reboot, all I got was a black screen when SDDM was meant to be executing.
Fedora Core 40 locks the root account, which means the rescue option in GRUB doesn’t work. And since root is locked, I can’t boot single user mode – that prompts for a root password. Instead, I booted from an external drive that has about 15 different OS installers and rescue tools on it, and poked around in the filesystem of my main OS.
After a bit of poking, and finding out that the Ubuntu install I had booted from has a journalctl that’s too old to read the journal files on disk, I remembered the way I used to solve this type of problem and chrooted into the main OS. Hey presto, journalctl now works, because I’m loading the one that’s from the main OS, not the rescue OS.
Jul 13 08:22:11 barracuda audit[1098]: AVC avc: denied { open } for pid=1098 comm="dbus-broker-lau" path="/etc/group" dev="nvme0n1p2" ino=3146688 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
Jul 13 08:22:11 barracuda audit[1098]: SYSCALL arch=c000003e syscall=257 success=no exit=-13 a0=ffffff9c a1=562631e7cd19 a2=80000 a3=0 items=0 ppid=1 pid=1098 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="dbus-broker-lau" exe="/usr/bin/dbus-broker-launch" subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null)
Jul 13 08:22:11 barracuda audit: PROCTITLE proctitle=2F7573722F62696E2F646275732D62726F6B65722D6C61756E6368002D2D73636F70650073797374656D002D2D6175646974
Jul 13 08:22:11 barracuda dbus-broker-launch[1098]: ERROR nss_cache_populate_groups @ ../src/launch/nss-cache.c +278: Permission denied
Jul 13 08:22:11 barracuda dbus-broker-launch[1098]: nss_cache_populate @ ../src/launch/nss-cache.c +316
Jul 13 08:22:11 barracuda dbus-broker-launch[1098]: launcher_run @ ../src/launch/launcher.c +1325
Jul 13 08:22:11 barracuda dbus-broker-launch[1098]: run @ ../src/launch/main.c +152
Jul 13 08:22:11 barracuda dbus-broker-launch[1098]: main @ ../src/launch/main.c +178
Jul 13 08:22:11 barracuda dbus-broker-launch[1098]: Exiting due to fatal error: -13
Jul 13 08:22:11 barracuda systemd[1]: dbus-broker.service: Main process exited, code=exited, status=1/FAILURE
Jul 13 08:22:11 barracuda systemd[1]: dbus-broker.service: Failed with result 'exit-code'.
Jul 13 08:22:11 barracuda systemd[1]: Failed to start dbus-broker.service - D-Bus System Message Bus.Well, there’s your problem – dbus broker can’t read /etc/group, and it’s not the traditional permissions problem, it’s SELinux. I didn’t even realise this machine ran SELinux in enforcing mode. For a quick solution, after some searching, I found the config in /etc/selinux to change SELinux over to permissive mode. Rebooted, and the broker is happy and everything works.
It turned out that something, somehow, mucked with /etc/group‘s SELinux context information, removing passwd_file_t from it. Restored it with semanage fcontext and restorecon, and I don’t see error logs any more (in permissive mode at least, there should be logs when a failure would have happened).
In reviewing the journal to make this post, I’ve noticed that at one point /etc/ld.so.cache became unlabeled_t, when it should be ld_so_cache_t. However, it’s sorted itself out, so it remains a mystery. I can also see the breakage I caused by removing /etc/resolv.conf‘s symlink when I was chrooted; with systemd, that file points to a stub that’s not available when chrooting from a rescue environment, and I needed name resolution to work. However, because I set permissive mode, everything worked (and I restored the symlink).
AVC avc: denied { getattr } for pid=1116 comm="systemd-resolve" path="/etc/resolv.conf" ... tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=1And something has broken /etc/shadow too
AVC avc: denied { open } for pid=1108 comm="systemd-userwor" path="/etc/shadow" ...
root@barracuda:~# ls -Z /etc/shadow
system_u:object_r:unlabeled_t:s0 /etc/shadow
root@barracuda:~# semanage fcontext -a -t shadow_t /etc/shadow
root@barracuda:~# restorecon -v /etc/shadow
Relabeled /etc/shadow from system_u:object_r:unlabeled_t:s0 to system_u:object_r:shadow_t:s0Very odd. I’ve ended up doing restorecon /usr/lib/* and restorecon /usr/lib64/* and restorecon /etc/* as a “sweep with a big broom” type cleanup.
Guess I’ll need to use the audit report tooling over the next few days to see what I missed. In the meantime, SELinux is staying in permissive mode.