Description of problem: X will not start in enforcing mode. gnome-settings-daemon crashes even in permissive Version-Release number of selected component (if applicable): control-center-2.21.2-2.fc9 selinux-policy-3.2.3-1.fc9 xorg-x11-server-Xorg - 1.4.99.1-0.13.fc9.i386 How reproducible: Steps to Reproduce: 1. boot with enforcing=0 2. load gnome 3. notice gnome-settings-daemon crashed due to SELinux permissions. Actual results: Error message in popup for g-s-daemon Expected results: Normal functioning in enforcing. Additional info: I had to start the troubleshooter browser with the -S option. The -b option did not load the browser
Created attachment 286561 [details] Forgot the attachment for error output.
Fixed in selinux-policy-3.2.3-2
selinux-policy-3.2.3-2.fc9 doesn't fix this, even with a filesystem relabel.
Created attachment 289702 [details] SELinux Alert
This avc is being generated due to a leaked file descriptor in gdm. It has already been reported and should not effect the login process.
It still fails in enforcing from spawning. I still see the original error. What action can be taken to fix the leaked file descriptor?
Are you saying that you still can log in, in enforcing mode? This is probably fixed in selinux-policy-3.2.4-3.fc9 The gdm avc needs to be fixed in GDM, There is an open bug report.
No, I have to be in permissive. GDM fails to spawn in enforcing. I'll wait for the fix for the gdm problem. Thanks!
When you login what context are you getting? Updated policy has changed the default user to unconfined_u You can do this on your machine by executing # semanage login -m -s unconfined_u __default__ # semanage login -m -s unconfined_u root
Running those two commands did not make a difference for me. Currently SELInix is even preventing me from logging in, performing commands like setenforce without getting a setenforce () or something similar. I relabeled the system, ran the commands followed by a reboot. No help.
Ok this is the hal breakage. Hal is reading a file from Policy Kit places in a bad directory. A patch has been sent to the hal/policykit maintainer. to fix the location. And as of tonight selinux-policy-3.2.5-3.fc9 will allow hal to read from the bad location. Hopefully PolicyKit will fix the bug soon, so I can revert the policy. Fixed for now in selinux-policy-3.2.5-3.fc9 Yo
selinux-policy-3.2.5-3.fc9 does patch the problem, Closing bug report and waiting for real fix in hal.