Red Hat Bugzilla – Bug 1287188
selinux preventing GDM and misc services from starting
Last modified: 2016-01-06 15:50:18 EST
Created attachment 1100975 [details]
Description of problem:
My system boots, but stops at:
Failed to start GNOME Display Manager.
See "systemctl status gdm.service" for details.
Starting Terminate Plymouth Boot Screen...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. upgrade packages
"Starting Terminate Plymouth Boot Screen..." (and all previous messages) remains on my screen and the login screen never appears.
gnome login screen displayed
appending selinux=0 to the kernel boot line gets around this every time.
I rebooted with selinux reenabled and the filesystems was relabled, but this didn't help. I also did a reinstall of the selinux policies but am still in the same boat.
boot in permissive mode enforcine=0 and then collect the avcs
ausearch -m avc
Created attachment 1101674 [details]
Have you been playing with containers?
Did you volume mount in /run with a :Z?
This would cause /run to be mislabeled. This is a bad idea, if you want to share /run into a container, you need to run --privileged.
restorecon -R -vF /run
Should fix the labels.
I personally have not volume-munted in /run. The only thing I ever -v is my pwd (while in my docker github repo) when running the tests.
I run the docker test suites a lot, but I don't see anything with Z and run.
# grep -r Z integration-cli/* | grep "\-v"
comes back empty.
The only thing I see after a few more greps is TestRunTmpfsMounts has some interesting mounts of /run, but nothing with :Z.
There was a bug in an older version of docker which was always doing a relabel, which could have caused the problem. I think it was in docker-engine, but I don't think Fedora released it.
I've kept Fedora versions of docker on my workstation since I installed it a few months ago -- currently Client/Server Version: 1.8.2-fc22. I can always try the relabel and see if I can recreate it. I'll wait to hear a "yes" from you guys though, in case you want any other debug info.
No that should be fine. You should fix the labels.
Created attachment 1103693 [details]
ausearch outputs after restorecon
Created attachment 1103694 [details]
ls -laZ of /run
Hm, so, the relabel didn't get me around the boot issue.
The labels look okay after the restorecon (although I didn't check them before, and I also am not an selinux expert). I attached the output of ls -laZ /run, and also the denials again after an enforcing=1 and an enforcing=0 boot.
I also triggered a relabel at boot (selinux=0 then selinux=1), which didn't change anything as far as I can tell.
I can't quite piece together how the svirt_sandbox_file_t type comes into play here.
They are all tclass=lnk_file. Is this device-mapper related?
ls -lZ /var/run
lrwxrwxrwx. 1 root root system_u:object_r:var_run_t:s0 6 Oct 21 2014 /var/run -> ../run
This is mine:
> ls -lZ /var/run
lrwxrwxrwx. 1 root root system_u:object_r:svirt_sandbox_file_t:s0:c513,c1004 6 May 21 2015 /var/run -> ../run
Which is wrong. Fix that with the restorecon command
restorecon -F /var/run