Bug 468530 - SELinux is preventing gdm-binary (xdm_t) "unlink" to ./force-display-on-active-vt (var_spool_t).
SELinux is preventing gdm-binary (xdm_t) "unlink" to ./force-display-on-activ...
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F10Blocker/F10FinalBlocker
  Show dependency treegraph
Reported: 2008-10-25 12:51 EDT by Jim Meyering
Modified: 2016-04-26 16:34 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-28 08:39:17 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 Jim Meyering 2008-10-25 12:51:40 EDT
Description of problem: no gdm greeter on rawhide

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

How reproducible: always

Steps to Reproduce:
1. try to boot into X
2. end up with black screen, resort to using a VT, then start X manually
Actual results: 
as above

Expected results:
to see gdm's username/password display

Additional info:

I fixed it (temporarily) by running this:

   restorecon /var/spool/gdm/force-display-on-active-vt

SELinux is preventing gdm-binary (xdm_t) "unlink" to
./force-display-on-active-vt (var_spool_t). The SELinux type var_spool_t, is a
generic type for all files in the directory and very few processes (SELinux
Domains) are allowed to write to this SELinux type. This type of denial usual
indicates a mislabeled file. By default a file created in a directory has the
gets the context of the parent directory, but SELinux policy has rules about the
creation of directories, that say if a process running in one SELinux Domain
(D1) creates a file in a directory with a particular SELinux File Context (F1)
the file gets a different File Context (F2). The policy usually allows the
SELinux Domain (D1) the ability to write, unlink, and append on (F2). But if for
some reason a file (./force-display-on-active-vt) was created with the wrong
context, this domain will be denied. The usual solution to this problem is to
reset the file context on the target file, restorecon -v
'./force-display-on-active-vt'. If the file context does not change from
var_spool_t, then this is probably a bug in policy. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy
package. If it does change, you can try your application again to see if it
works. The file context could have been mislabeled by editing the file or moving
the file from a different directory, if the file keeps getting mislabeled, check
the init scripts to see if they are doing something to mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v

Fix Command:

restorecon './force-display-on-active-vt'

Additional Information:

Source Context                system_u:system_r:xdm_t:s0-s0:c0.c1023
Target Context                system_u:object_r:var_spool_t:s0
Target Objects                ./force-display-on-active-vt [ file ]
Source                        gdm-binary
Source Path                   /usr/sbin/gdm-binary
Port                          <Unknown>
Host                          vv.meyering.net
Source RPM Packages           gdm-2.24.0-11.fc10
Target RPM Packages           
Policy RPM                    selinux-policy-3.5.13-5.fc10
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   mislabeled_file
Host Name                     vv.meyering.net
Platform                      Linux vv.meyering.net #1
                              SMP Wed Oct 22 21:04:28 EDT 2008 x86_64 x86_64
Alert Count                   295
First Seen                    Mon 20 Oct 2008 09:28:36 AM CEST
Last Seen                     Sat 25 Oct 2008 06:07:45 PM CEST
Local ID                      c8d5ca79-7c6f-4d9e-865f-2894f611277d
Line Numbers                  

Raw Audit Messages            

node=vv.meyering.net type=AVC msg=audit(1224950865.447:64): avc:  denied  { unlink } for  pid=2840 comm="gdm-binary" name="force-display-on-active-vt" dev=sda1 ino=262311 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_spool_t:s0 tclass=file

node=vv.meyering.net type=SYSCALL msg=audit(1224950865.447:64): arch=c000003e syscall=87 success=no exit=-13 a0=41bbe8 a1=0 a2=1 a3=8101010101010100 items=0 ppid=1 pid=2840 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gdm-binary" exe="/usr/sbin/gdm-binary" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
Comment 1 Daniel Walsh 2008-10-27 10:10:49 EDT
This looks like /var/spool/gdm is not labeled correctly.

restorecon -R -v /var/spool

Should fix.

I have no idea how this got mislabeled, did you remove and readd the directory?
Comment 2 Jim Meyering 2008-10-27 10:58:25 EDT
Hi Dan,

No, I never removed either of those directories,
and that restorecon command affected only the cron files:

# ls -dlZ /var/spool /var/spool/gdm 
drwxr-xr-x+ 12 root root system_u:object_r:var_spool_t:s0 4096 2008-10-21 10:20 /var/spool/
drwxrwxr-x+  2 root root system_u:object_r:xdm_spool_t:s0 4096 2008-10-27 07:49 /var/spool/gdm/
# restorecon -R -v /var/spool
restorecon reset /var/spool/anacron/cron.daily context system_u:object_r:var_spool_t:s0->system_u:object_r:system_cron_spool_t:s0
restorecon reset /var/spool/anacron/cron.weekly context system_u:object_r:var_spool_t:s0->system_u:object_r:system_cron_spool_t:s0
restorecon reset /var/spool/anacron/cron.monthly context system_u:object_r:var_spool_t:s0->system_u:object_r:system_cron_spool_t:s0
Comment 3 Daniel Walsh 2008-10-27 15:22:57 EDT
Jim. Where is the file

Comment 4 Jim Meyering 2008-10-27 16:07:27 EDT
Comment 5 Daniel Walsh 2008-10-28 08:39:17 EDT
Jim you were not able to get this to happen again correct, so the only thing I canthink of was a mislabeling.    So unless you can get it to happen again, I am going to close this bug.
Comment 6 Jim Meyering 2008-10-28 13:52:09 EDT
Dan, sounds good.  Thanks for investigating.

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