Bug 1287188 - selinux preventing GDM and misc services from starting
selinux preventing GDM and misc services from starting
Product: Fedora
Classification: Fedora
Component: docker (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Lokesh Mandvekar
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2015-12-01 12:30 EST by clnperez
Modified: 2016-01-06 15:50 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-06 15:50:18 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
boot.log (19.07 KB, text/plain)
2015-12-01 12:30 EST, clnperez
no flags Details
avc denials (194.45 KB, text/plain)
2015-12-02 23:55 EST, clnperez
no flags Details
ausearch outputs after restorecon (212.93 KB, text/plain)
2015-12-08 14:52 EST, clnperez
no flags Details
ls -laZ of /run (8.25 KB, text/plain)
2015-12-08 14:53 EST, clnperez
no flags Details

  None (edit)
Description clnperez 2015-12-01 12:30:23 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):


How reproducible:
every time

Steps to Reproduce:
1. upgrade packages
2. reboot

Actual results
"Starting Terminate Plymouth Boot Screen..." (and all previous messages) remains on my screen and the login screen never appears.

Expected results:
gnome login screen displayed

Additional info:
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.
Comment 1 Daniel Walsh 2015-12-01 13:13:01 EST
boot in permissive mode enforcine=0 and then collect the avcs

ausearch -m avc
Comment 2 clnperez 2015-12-02 23:55 EST
Created attachment 1101674 [details]
avc denials
Comment 3 Miroslav Grepl 2015-12-08 07:54:16 EST
Have you been playing with containers?
Comment 4 clnperez 2015-12-08 09:04:49 EST
Comment 5 Daniel Walsh 2015-12-08 09:39:43 EST
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.
Comment 6 clnperez 2015-12-08 11:05:31 EST
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.
Comment 7 Daniel Walsh 2015-12-08 11:53:43 EST
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.
Comment 8 clnperez 2015-12-08 12:20:10 EST
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.
Comment 9 Daniel Walsh 2015-12-08 12:34:02 EST
No that should be fine. You should fix the labels.
Comment 10 clnperez 2015-12-08 14:52 EST
Created attachment 1103693 [details]
ausearch outputs after restorecon
Comment 11 clnperez 2015-12-08 14:53 EST
Created attachment 1103694 [details]
ls -laZ of /run
Comment 12 clnperez 2015-12-08 14:53:56 EST
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?
Comment 13 Daniel Walsh 2015-12-09 14:09:49 EST
ls -lZ /var/run
lrwxrwxrwx. 1 root root system_u:object_r:var_run_t:s0 6 Oct 21  2014 /var/run -> ../run
Comment 14 clnperez 2015-12-20 18:39:20 EST
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
Comment 15 Daniel Walsh 2015-12-21 11:56:39 EST
Which is wrong.  Fix that with the restorecon command

restorecon -F /var/run

Note You need to log in before you can comment on or make changes to this bug.