Bug 179058 - X server segfault during rhgb or single-user mode run
X server segfault during rhgb or single-user mode run
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: synaptics (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-26 16:31 EST by Jason Vas Dias
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

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


Attachments (Terms of Use)
X server log from 'X -probeonly' ending with core dump (14.54 KB, text/plain)
2006-01-26 16:35 EST, Jason Vas Dias
no flags Details
/etc/X11/xorg.conf as requested (2.92 KB, text/plain)
2006-01-27 18:27 EST, Jason Vas Dias
no flags Details
Xorg.0.log from successful X run (when X runs in xdm_t context) (40.26 KB, text/plain)
2006-01-27 18:29 EST, Jason Vas Dias
no flags Details

  None (edit)
Description Jason Vas Dias 2006-01-26 16:31:51 EST
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:
Comment 1 Jason Vas Dias 2006-01-26 16:35:28 EST
Created attachment 123747 [details]
X server log from 'X -probeonly' ending with core dump
Comment 2 Jason Vas Dias 2006-01-27 11:38:26 EST
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.




Comment 3 Jason Vas Dias 2006-01-27 11:43:26 EST
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.
Comment 4 Mike A. Harris 2006-01-27 14:31:42 EST
Reassigning to synaptics component, as I can't think of any really good reason
why the synaptics driver should need to exec heap memory.
Comment 5 Jason Vas Dias 2006-01-27 16:58:22 EST
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.
Comment 6 Paul Nasrat 2006-01-27 17:59:21 EST
Out of curiosity can you attach your xorg.conf too.
Comment 7 Jason Vas Dias 2006-01-27 18:27:09 EST
Created attachment 123812 [details]
/etc/X11/xorg.conf as requested
Comment 8 Jason Vas Dias 2006-01-27 18:29:25 EST
Created attachment 123813 [details]
Xorg.0.log from successful X run (when X runs in xdm_t context)
Comment 10 Jason Vas Dias 2006-02-02 15:01:53 EST
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!

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