Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 166419 - gdm can't start any sessions whatsoever with targeted policy in enforcing mode
gdm can't start any sessions whatsoever with targeted policy in enforcing mode
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-08-20 16:45 EDT by Alexandre Oliva
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: selinux-policy-targeted-1.25.4-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-08-28 10:34:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2005-08-20 16:45:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b3) Gecko/20050818 Fedora/1.1-0.2.7.deerpark.alpha2.1 Firefox/1.0+

Description of problem:
After upgrading to today's rawhide, I could no longer start a failsafe terminal from gdm.  After saying displaying the dialogue in which it informs terminating the xterm will terminate the session, when you press enter, a new dialogue opens up saying an internal error occurred and the session couldn't be started.

It then says the session has left a ~/.xsession-errors file with errors, but no such file was created.

A new gdm login screen shows up afterwards.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Try to start a fail safe terminal from gdm

Actual Results:  It triggers an internal error in gdm

Expected Results:  It worked with yesterday's rawhide

Additional info:
Comment 1 Alexandre Oliva 2005-08-20 16:51:48 EDT
Turns out this is a selinux problem.  gdm-binary fails to exec xterm.  Here's
the audit.log snippet:

type=AVC msg=audit(1124569909.855:395): avc:  denied  { transition } for 
pid=4996 comm="gdm-binary" name="xterm" dev=dm-2 ino=1351752
scontext=system_u:system_r:init_t tcontext=user_u:system_r:unconfined_t
type=SYSCALL msg=audit(1124569909.855:395): arch=40000003 syscall=11 success=yes
exit=0 a0=892a780 a1=bff7eb30 a2=892a488 a3=891ad1c items=2 pid=4996
auid=4294967295 uid=404 gid=404 euid=404 suid=404 fsuid=404 egid=404 sgid=404
fsgid=404 comm="xterm" exe="/usr/bin/xterm"
type=AVC_PATH msg=audit(1124569909.855:395):  path="/usr/bin/xterm"
type=CWD msg=audit(1124569909.855:395):  cwd="/l/home/aoliva"
type=PATH msg=audit(1124569909.855:395): item=0 name="/usr/bin/xterm" flags=101
 inode=1351752 dev=fd:02 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1124569909.855:395): item=1 flags=101  inode=266082
dev=fd:02 mode=0100755 ouid=0 ogid=0 rdev=00:00

Should gdm-binary be running as init_t, or is this a fallout from changes in
file names in gdm that require changes in the selinux context specs?

A simple work-around to get a failsafe term is to setenforce 0.
Comment 2 Alexandre Oliva 2005-08-20 17:24:12 EDT
It turns out that it's not only the failsafe terminal that's broken.  Starting a
default (gnome) session is broken in just the same way :-(
Comment 3 Alexandre Oliva 2005-08-20 17:28:39 EDT
I forgot to post the audit logs for the default session, here they are:

type=AVC msg=audit(1124572643.945:81): avc:  denied  { transition } for 
pid=3518 comm="gdm-binary" name="Xsession" dev=dm-1 ino=362615
scontext=system_u:system_r:init_t tcontext=user_u:system_r:unconfined_t
type=SYSCALL msg=audit(1124572643.945:81): arch=c000003e syscall=59 success=yes
exit=0 a0=646350 a1=7fffffd3dcd0 a2=66bb60 a3=66c200 items=3 pid=3518
auid=4294967295 uid=404 gid=404 euid=404 suid=404 fsuid=404 egid=404 sgid=404
fsgid=404 comm="Xsession" exe="/bin/bash"
type=AVC_PATH msg=audit(1124572643.945:81):  path="/etc/X11/xdm/Xsession"
type=CWD msg=audit(1124572643.945:81):  cwd="/l/home/aoliva"
type=PATH msg=audit(1124572643.945:81): item=0 name="/etc/X11/xdm/Xsession"
flags=101  inode=362615 dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1124572643.945:81): item=1 flags=101  inode=1998886
dev=fd:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1124572643.945:81): item=2 flags=101  inode=951472 dev=fd:01
mode=0100755 ouid=0 ogid=0 rdev=00:00
Comment 4 Tom London 2005-08-21 21:13:29 EDT
Problem appears to be caused by the 'moving' of gdm-binary from /usr/bin to

The following 'patch' made it work for me (of course, you need to 'make load'):

--- /tmp/xdm.fc 2005-08-21 18:12:10.000000000 -0700
+++ ./xdm.fc    2005-08-21 17:55:35.000000000 -0700
@@ -3,7 +3,7 @@
 /usr/X11R6/bin/[xgkw]dm        --      system_u:object_r:xdm_exec_t
 /opt/kde3/bin/kdm      --      system_u:object_r:xdm_exec_t
 /usr/bin/gpe-dm                --      system_u:object_r:xdm_exec_t
-/usr/bin/gdm-binary    --      system_u:object_r:xdm_exec_t
+/usr/(s)?bin/gdm-binary        --      system_u:object_r:xdm_exec_t
 /var/[xgk]dm(/.*)?             system_u:object_r:xserver_log_t
 /usr/var/[xgkw]dm(/.*)?                system_u:object_r:xserver_log_t
 /var/log/[kw]dm\.log   --      system_u:object_r:xserver_log_t
Comment 5 Fred New 2005-08-22 07:04:56 EDT
So for now, one workaround that allows you to stay in enforcing mode is to
   chcon -t xdm_exec_t /usr/sbin/gdm-binary
and reboot.
Comment 6 Daniel Walsh 2005-08-25 09:31:56 EDT
selinux-policy-targeted-1.25.4-8 has fix
Comment 7 Alexandre Oliva 2005-08-28 10:34:21 EDT
Fixed, indeed.  Thanks!

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