i was playing around getting stumpwm running on silverblue rawhide and tried to install a .desktop file for gdm. i dropped the file in /etc/X11/session which did not work, so i thought it might be an issue with a selinux label. so i ran fixfiles restore /etc/X11 which did not change anything, so i manually ran chcon -u system_u /etc/X11/sessions/stumpwm.session which changed the user to system_u. so far so good
but after rebooting it seems that all selinux labels on the filesystem got reset to default_t. maybe (or for sure…) i did something completely stupid while hacking around…
i’m currently looking only at systemd as starting various services failed because of this.
# ls -laZ /usr/lib/systemd/systemd
-rwxr-xr-x. 4 root root system_u:object_r:default_t:s0 2402648 Jan 1 1970 /usr/lib/systemd/systemd
on a silverblue vagrant box which is working fine this yields
# ls -laZ /usr/lib/systemd/systemd
-rwxr-xr-x. 4 root root system_u:object_r:init_exec_t:s0 2402648 Dec 31 1969 /usr/lib/systemd/systemd
looking at more files it seems all domains got reset to default_t
what is the recommend way to restore the right selinux labels under silverblue?
i tried touching /.autorelabel, but of course this does not work on silverblue. fixfiles -F onboot also fails because of this:
# ]# fixfiles -F onboot
/usr/sbin/fixfiles: line 313: /.autorelabel: Operation not permitted
i’m currently running selinux in permissive mode, but a fix without reinstalling would be great
thanks for the hint. semodule -B worked. fixfiles check /usr/lib/systemd now reports that it would fix the labels. problem is that fixfiles restore /usr/lib/systemd is not able to modify /usr (as expected on silverblue). so the question is how to relabel files in /usr in silverblue?
i could probably run fixfiles/restorecon in /sysroot/ostree/deploy/fedora-workstation/deploy and relabel the ostree checkouts, but is this a good idea?
Files under /usr should always have the correct label since those are part of the OSTree object itself. If they’re not labeled correctly, then your repo might somehow be corrupted. Does ostree fsck return any errors for you? Hmm… unless you have layered packages that are affecting your policy. rpm-ostree status -v would be helpful. There’s an outstanding issue related to this: 1669982 – Selinux context for /home symlink to /var/home wrong (silverblue, causes failed boots)
(By contrast, files in /etc and /var could become mislabeled depending on what you’re doing and so restorecon on those could make sense.)
I believe you should be able to just re-pull the corrupted commits:
# ostree pull <remote-name>:<ref> <commit>
I just successfully did the following:
$ sudo ostree pull fedora-workstation:fedora/29/x86_64/silverblue a6b10956f6ccb594101a9364d52fdb0ae6ff63dda481fa1e9d5419b7c39c38d0
GPG: Verification enabled, found 1 signature:
Signature made Tue 12 Feb 2019 08:28:54 PM EST using RSA key ID A20AA56B429476B4
Good signature from "Fedora 29 <fedora-29@fedoraproject.org>"
1 metadata, 0 content objects fetched; 569 B transferred in 3 seconds
just a quick update: i actually reinstalled silverblue to finally fix this issues. mounting /usr rw and running fixfiles somehow worked, but the links in / (e.g bin, sbin) still had wrong labels. as i was unsure if everything was labeled correctly i simply reinstalled.
i’m not sure how to really fix this issue. i think i did a rebase once but this didn’t fix anything. but you could try it anyways. relabeling everything somehow worked, but i still had minor issues (some services still failing). the only real fix for me was to reinstall.
in a standard installation of rhel/fedora you could always touch /.autorelabel and reboot, but imho this does not work for silverblue.
one outcome of the above was that i only install a minimal set of overlay packages (like i3) and everything else is running inside a toolbox container (you could also use flatpak). i think this the way to go with silverblue anyways.
sorry that i cannot provide an easy fix for that issue
Same thing happened to me after I ran semodule -B as suggested by @miabbott above, the boot error for me was unable to locate selinux policy or something.
I also observed this:
And although the suggested fix # ostree pull <remote-name>:<ref> <commit> exits successfully, the output of the ostree fsck remains the same.
I got into this mess after running this command and extremely foolishly deciding to blast /etc/selinux out of the water. That did fix the issue I was having, but of course broke SELinux. I only noticed when trying to upgrade zoom, eventually seeing the SELinux troubleshooter would not launch, SELinux was disabled, and that I got the same output from attempting to relabel:
…which brings me to this thread.
Now I just want to know how can I give SELinux a fresh start? I tried copying over /etc/selinux from my working laptop, but that didn’t get me to a working login prompt. Is there any way to recover from purging /etc/selinux?
Edit: The docs explain this, but I am still unable with SELinux enabled after running this
Wow, good to know! I tried the steps in that ticket but I still am unable to boot with:
Maybe I messed up a step-- I can try again tomorrow.
Edit: Tried again and it worked! Thank you! Also, for search-ability, the error I actually get issystemd-logind.service: Failed to connect stdout to the journal socket, ignoring: Connection refused.