Description of problem: rhgb stopped being run during boot, on my IBM Thinkpad T41 laptop (radeon graphics), with recent kernels (I think 2.6.15-1.1869+ ) . Booting into single user mode and running 'X -probeonly', the X server catches a SIGSEGV during load of the synaptics_drv module, as shown in the attached /var/log/Xorg.0.log.old from the run. After booting into runlevel 5, the driver loads OK, and X is able to run. Installing the xorg-x11-server debuginfo package, I got this stack trace: $ gdb /usr/bin/X core.1958 GNU gdb Red Hat Linux (6.3.0.0-1.98rh) ... Core was generated by `X -probeonly'. Program terminated with signal 6, Aborted. ... (gdb) where #0 0x009bd402 in __kernel_vsyscall () #1 0x0014c079 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x0014d613 in *__GI_abort () at abort.c:88 #3 0x0809f40d in ddxGiveUp () at xf86Init.c:1258 #4 0x081a9652 in AbortServer () at log.c:408 #5 0x081a9bc4 in FatalError (f=0x81b7ed4 "Caught signal %d. Server aborting\n") at log.c:554 #6 0x080b5d66 in xf86SigHandler (signo=11) at xf86Events.c:1495 #7 <signal handler called> #8 0x080a47f4 in LoadModule (module=Variable "module" is not available. ) at loadmod.c:1036 #9 0x0809eed3 in xf86LoadModules (list=0x823b9d8, optlist=0x823dee8) at xf86Init.c:1961 #10 0x0809feb5 in InitOutput (pScreenInfo=0x8201f20, argc=2, argv=0xbffe22e4) at xf86Init.c:413 #11 0x0806feeb in main (argc=2, argv=0xbffe22e4, envp=0xbffe22f0) at main.c:372 (gdb) The last messages from the X server log are: ' (II) Module synaptics: vendor="X.Org Foundation" compiled for 4.3.99.902, module version = 1.0.0 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 0.5 *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting ' So I'm assuming it was the synaptics_drv load that causes the core dump when it occurs in single-user mode. Version-Release number of selected component (if applicable): synaptics-0.14.4-4.1 xorg-x11-server-Xorg-1.0.0-3 How reproducible: 100% Steps to Reproduce: 1. Boot into single-user mode 2. Run 'X -probeonly' Actual results: Server exits with core dump Expected results: Server should probe hardware correctly and exit. Additional info:
Created attachment 123747 [details] X server log from 'X -probeonly' ending with core dump
This turns out to be an SELinux issue - problem does not occur with SELinux in permissive mode. Here are the AVCs generated: allow unconfined_t self:process execheap; type=AVC msg=audit(1138379116.505:94): avc: denied { execheap } for pid=2014 comm="X" scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=process Perhaps X should have its own SELinux context that allows execheap privilege.
Either synaptics_drv should avoid having to exec heap memory, or SELinux must allow X to do so - otherwise rhgb is disabled during boot if synaptics touchpad is installed and SELinux is in enforcing mode.
Reassigning to synaptics component, as I can't think of any really good reason why the synaptics driver should need to exec heap memory.
What's weird about this is why in single-user mode / when rhgb is run, synaptics_drv needs to exec heap memory, but when run from the display manager, it apparently does not. ie. ONLY when run from xdm / prefdm / kdm, can my X server run at all, with SELinux in Enforcing mode. Any attempt to run X from the command line with SELinux enabled, ie. from Xsession / startx, or 'X -probeonly', results in the Abort in the same place, on the attempt to load the synaptics driver. kdm (the DM I use) and xdm have context 'system_u:object_r:xdm_exec_t', while X and gdm have the default context system_u:object_r:bin_t / sbin_t . Aha ! maybe this is why gdm cannot run X on my system either ... Indeed, only when X is run with xdm_t context, it is granted the execmem privilege: type=AVC msg=audit(1138394146.502:311): avc: granted { execmem } for pid=4020 comm="X" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=process type=AVC msg=audit(1138394146.506:312): avc: granted { execmem } for pid=4020 comm="X" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=process type=AVC msg=audit(1138394146.506:312): avc: granted { execmem } for pid=4020 comm="X" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=process type=AVC msg=audit(1138394146.506:313): avc: granted { execmem } for pid=4020 comm="X" scontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c255 tclass=process When X is run under any other context than xdm_t:s0-s0:c0.c255, it cannot "execmem". The fact that this happens 4 times suggests that it is not only the synaptics driver load that causes the execmem.
Out of curiosity can you attach your xorg.conf too.
Created attachment 123812 [details] /etc/X11/xorg.conf as requested
Created attachment 123813 [details] Xorg.0.log from successful X run (when X runs in xdm_t context)
Hooray! This bug is now magically fixed with today's Rawhide (20060201), and selinux-policy-targeted-2.2.9-2, now that /usr/bin/Xorg has context system_u:object_r:xserver_exec_t - rhgb now starts and X can be run outside of xdm OK - thanks!