Bug 521752

Summary: setroubleshoot: SELinux is preventing Xorg "read write" access to device vga_arbiter.
Product: [Fedora] Fedora Reporter: pavel mikula <pavel.mikula>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: dwalsh, harald, mgrepl, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: setroubleshoot_trace_hash:1652209030fd4a252fd374116bab7334005312c0f0a10c4bc40277d205f75d86
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-26 06:07:21 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description pavel mikula 2009-09-08 02:33:12 EDT
The following was filed automatically by setroubleshoot:

Summary:

SELinux is preventing Xorg "read write" access to device vga_arbiter.

Detailed Description:

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

SELinux has denied Xorg "read write" access to device vga_arbiter. vga_arbiter
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 'vga_arbiter'.
If this device remains labeled device_t, then this is a bug in SELinux policy.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against the selinux-policy package. If you look at the other similar devices
labels, ls -lZ /dev/SIMILAR, and find a type that would work for vga_arbiter,
you can use chcon -t SIMILAR_TYPE 'vga_arbiter', If this fixes the problem, you
can make this permanent by executing semanage fcontext -a -t SIMILAR_TYPE
'vga_arbiter' 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 (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this
application.

Allowing Access:

Attempt restorecon -v 'vga_arbiter' or chcon -t SIMILAR_TYPE 'vga_arbiter'

Additional Information:

Source Context                system_u:system_r:xserver_t:s0-s0:c0.c1023
Target Context                system_u:object_r:device_t:s0
Target Objects                vga_arbiter [ chr_file ]
Source                        Xorg
Source Path                   /usr/bin/Xorg
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           xorg-x11-server-Xorg-1.6.99-43.20090828.fc12
Target RPM Packages           
Policy RPM                    selinux-policy-3.6.30-1.fc12
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   device
Host Name                     (removed)
Platform                      Linux (removed) 2.6.31-0.190.rc8.fc12.i686 #1
                              SMP Fri Aug 28 19:07:13 EDT 2009 i686 i686
Alert Count                   2
First Seen                    Wed 02 Sep 2009 03:58:58 PM CEST
Last Seen                     Wed 02 Sep 2009 03:58:58 PM CEST
Local ID                      9021cd33-4262-4abd-a951-6d9d4c541c7a
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1251899938.609:100): avc:  denied  { read write } for  pid=17275 comm="Xorg" name="vga_arbiter" dev=tmpfs ino=3531 scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=(removed) type=AVC msg=audit(1251899938.609:100): avc:  denied  { open } for  pid=17275 comm="Xorg" name="vga_arbiter" dev=tmpfs ino=3531 scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=(removed) type=SYSCALL msg=audit(1251899938.609:100): arch=40000003 syscall=5 success=yes exit=8 a0=80fdf7 a1=2 a2=b12ef0 a3=811240 items=0 ppid=17274 pid=17275 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty7 ses=4294967295 comm="Xorg" exe="/usr/bin/Xorg" subj=system_u:system_r:xserver_t:s0-s0:c0.c1023 key=(null)


audit2allow suggests:

#============= xserver_t ==============
allow xserver_t device_t:chr_file { read write open };
Comment 1 Daniel Walsh 2009-09-08 10:44:44 EDT
Is X creating this device?
Comment 2 Matěj Cepl 2009-11-05 12:14:55 EST
Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]
Comment 3 Bug Zapper 2009-11-16 07:02:47 EST
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Adam Jackson 2009-12-09 12:22:48 EST
Dan, X should not be creating this device.  It should be created by udev before X ever gets to it.
Comment 5 Daniel Walsh 2009-12-09 12:38:04 EST
Then udev created it with the wrong context.
Comment 7 Harald Hoyer 2010-01-26 06:07:21 EST

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