Red Hat Bugzilla – Bug 422891
SELinux is preventing Xorg (xdm_xserver_t) "sys_ptrace" to (xdm_xserver_t).
Last modified: 2007-12-21 23:49:59 EST
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):
xorg-x11-server-Xorg - 184.108.40.206-0.13.fc9.i386
Steps to Reproduce:
1. boot with enforcing=0
2. load gnome
3. notice gnome-settings-daemon crashed due to SELinux permissions.
Error message in popup for g-s-daemon
Normal functioning in enforcing.
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]
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
selinux-policy-3.2.5-3.fc9 does patch the problem, Closing bug report and
waiting for real fix in hal.