Bug 628077 - SELinux is preventing /usr/bin/Xorg "getattr" access to device /dev/dri/card0.
SELinux is preventing /usr/bin/Xorg "getattr" access to device /dev/dri/card0.
Status: CLOSED DUPLICATE of bug 566332
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
14
i386 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:3e315288757...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-27 15:49 EDT by William Makowski
Modified: 2010-08-30 19:04 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-30 19:04:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Xorg log (29.35 KB, text/plain)
2010-08-30 10:41 EDT, William Makowski
no flags Details

  None (edit)
Description William Makowski 2010-08-27 15:49:00 EDT
Summary:

SELinux is preventing /usr/bin/Xorg "getattr" access to device /dev/dri/card0.

Detailed Description:

[X has a permissive type (xserver_t). This access was not denied.]

SELinux has denied X "getattr" access to device /dev/dri/card0. /dev/dri/card0
is mislabeled, this device has the default label of the /dev directory, which
should not happen. All Character and/or Block Devices should have a label. You
can attempt to change the label of the file using restorecon -v
'/dev/dri/card0'. If this device remains labeled device_t, then this is a bug in
SELinux policy. Please file a bg report. If you look at the other similar
devices labels, ls -lZ /dev/SIMILAR, and find a type that would work for
/dev/dri/card0, you can use chcon -t SIMILAR_TYPE '/dev/dri/card0', If this
fixes the problem, you can make this permanent by executing semanage fcontext -a
-t SIMILAR_TYPE '/dev/dri/card0' If the restorecon changes the context, this
indicates that the application that created the device, created it without using
SELinux APIs. If you can figure out which application created the device, please
file a bug report against this application.

Allowing Access:

Attempt restorecon -v '/dev/dri/card0' or chcon -t SIMILAR_TYPE '/dev/dri/card0'

Additional Information:

Source Context                unconfined_u:unconfined_r:xserver_t:s0-s0:c0.c1023
Target Context                system_u:object_r:device_t:s0
Target Objects                /dev/dri/card0 [ chr_file ]
Source                        X
Source Path                   /usr/bin/Xorg
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           xorg-x11-server-Xorg-1.9.0-2.fc14
Target RPM Packages           
Policy RPM                    selinux-policy-3.8.8-20.fc14
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   device
Host Name                     (removed)
Platform                      Linux (removed) 2.6.35.2-9.fc14.i686.PAE #1 SMP Tue
                              Aug 17 22:36:11 UTC 2010 i686 i686
Alert Count                   1
First Seen                    Fri 27 Aug 2010 12:03:04 AM EDT
Last Seen                     Fri 27 Aug 2010 12:03:04 AM EDT
Local ID                      4cede82a-63b7-47cf-9deb-f05da4c82eaa
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1282881784.298:17): avc:  denied  { getattr } for  pid=1108 comm="X" path="/dev/dri/card0" dev=devtmpfs ino=14322 scontext=unconfined_u:unconfined_r:xserver_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=(removed) type=SYSCALL msg=audit(1282881784.298:17): arch=40000003 syscall=195 success=yes exit=0 a0=bfd1c1bc a1=bfd1c148 a2=ab4ff4 a3=1 items=0 ppid=1107 pid=1108 auid=500 uid=500 gid=500 euid=0 suid=0 fsuid=0 egid=500 sgid=500 fsgid=500 tty=tty7 ses=1 comm="X" exe="/usr/bin/Xorg" subj=unconfined_u:unconfined_r:xserver_t:s0-s0:c0.c1023 key=(null)



Hash String generated from  device,X,xserver_t,device_t,chr_file,getattr
audit2allow suggests:

#============= xserver_t ==============
allow xserver_t device_t:chr_file getattr;
Comment 1 Miroslav Grepl 2010-08-30 06:15:08 EDT
This device should be labeled correctly by udev. Could you check the current label on the device?

# ls -Z /dev/dri/card0


Should be 

ls -Z /dev/dri/card0 
crw-rw----+ root video system_u:object_r:dri_device_t:s0 /dev/dri/card0

If your label is different, execute

restorecon -v /dev/dri/card0

Will fix.

Any idea how this label got created?
Comment 2 William Makowski 2010-08-30 10:41:40 EDT
Created attachment 441955 [details]
Xorg log

The label on the device appears to be the same as what you have.

[root@pippin ~]# ls -Z /dev/dri/card0
crw-rw----+ root video system_u:object_r:dri_device_t:s0 /dev/dri/card0

I ran restorecon -v /dev/dri/card0 and the label is still the same...

[root@pippin ~]# restorecon -v /dev/dri/card0
[root@pippin ~]# ls -Z /dev/dri/card0
crw-rw----+ root video system_u:object_r:dri_device_t:s0 /dev/dri/card0

It looks like this device is created (opened) by Xorg.  I am attaching my Xorg.0.log.  You can find the entry by searching for /dev/dri/card0 in the log.
Comment 3 William Makowski 2010-08-30 14:21:52 EDT
Correction, device is created by udev.  I changed udev_log="debug" in udev.conf and can see it being created in the messages log (see below).  However, the SELinux alert happens when Xorg opens the device.

Aug 30 14:03:09 pippin udevd-work[347]: creating device node '/dev/dri/card0', devnum=226:0, mode=0660, uid=0, gid=39
Aug 30 14:03:09 pippin udevd-work[347]: preserve file '/dev/dri/card0', because it has correct dev_t
Aug 30 14:03:09 pippin udevd-work[347]: set permissions /dev/dri/card0, 020660, uid=0, gid=39
Comment 4 Eric Paris 2010-08-30 19:04:31 EDT
Marking as a dup of 566332.  This looks like a udev bug introduced by:

http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=578cc8a8085a47c963b5940459e475ac5f07219c

Old udev would correct the selinux label unconditionally whereas new code only corrects it if the mask, uid, or gid is wrong.  This matches up with what comment #3 says about "preserve file '/dev/dri/card0', because it has correct dev_t"
Comment 5 Eric Paris 2010-08-30 19:04:49 EDT

*** This bug has been marked as a duplicate of bug 566332 ***

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