Bug 120885 - xorg-x11 changes give MapVidMem problems accessing /dev/mem
Summary: xorg-x11 changes give MapVidMem problems accessing /dev/mem
Alias: None
Product: Fedora
Classification: Fedora
Component: policy   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-14 20:39 UTC by Gene Czarcinski
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-28 13:10:53 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
/var/log/messages (15.85 KB, text/plain)
2004-04-14 20:40 UTC, Gene Czarcinski
no flags Details

Description Gene Czarcinski 2004-04-14 20:39:25 UTC
Description of problem:
policy-1.11.2-3 installed.

xorg-x11-*-6.7.0-0.4 installed

With enforcing=1 and runlevel=5 boot, gdm (and X) have a problem
during startup causing X not to start.  The problem is that MapVidMem
cannot access /dev/mem:

crw-r-----+ root     kmem     system_u:object_r:memory_device_t /dev/mem

I am attaching the last 200 lines from /var/log/messages which have
the relevant "denied" messages.

Comment 1 Gene Czarcinski 2004-04-14 20:40:07 UTC
Created attachment 99428 [details]

Comment 2 Daniel Walsh 2004-04-14 21:53:37 UTC
This is a file context file problem caused by Xorg running under the
wrong context.  You need policy-1.11.2-3 and to 
restorecon /usr/bin/X11/Xorg /var/log/Xorg*

Comment 3 Gene Czarcinski 2004-04-14 22:19:01 UTC
As I explained elsewhere, you need to run:

  restorecon /usr/X11R6/bin/Xorg

rather than

  restorecon /usr/bin/X11/Xorg

since /etc/security/selinux/src/policy/* only specified
/usr/X11R6/bin/Xorg for xserver_exec_t

Comment 4 Gene Czarcinski 2004-04-14 22:24:37 UTC
BTW, this info needs posting on the mailing list.  Just installing the
new policy (assume it will be in tomorrows development), does not fix

One thing I have learned out of this is that the complete path to a
file makes a really big difference as to what attributes it is
assigned and symlinks can really screw things up.  I seem to remember
that Mike Harris mentioned wanting to get rid of all the X11 and
/usr/X11R6 stuff and put everything into /usr/bin ... that sure would
make things simpler.

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