Bug 176221 - "SELinux" prevents "DRI" modules from being loaded
"SELinux" prevents "DRI" modules from being loaded
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Depends On:
  Show dependency treegraph
Reported: 2005-12-20 05:57 EST by Joachim Frieben
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-27 17:48:00 EST
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 Joachim Frieben 2005-12-20 05:57:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051215 Epiphany/

Description of problem:
After upgrading to the latest "Mesa" packages, "DRI" is
not available anymore. Launching a suitable application
with "LIBGL_DEBUG" set to "verbose", the following error
message is issued:

"libGL error: dlopen /usr/lib/dri/savage_dri.so failed (/usr/lib/dri/savage_dri.so: cannot restore segment prot
after reloc: Permission denied)libGL error: unable to find
driver: savage_dri.so"

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

How reproducible:

Steps to Reproduce:
1. Execute "env LIBGL_DEBUG=verbose glxgears".

Actual Results:  Hardware acceleration is disabled. "Mesa" issues: "unable to find
driver: savage_dri.so"

Expected Results:  The "savage_dri.so" should get loaded, and hardware acceleration
should be enabled.

Additional info:

Execution of

"chcon system_u:object_r:texrel_shlib_t /usr/lib/dri/*so"

allows to restore hardware acceleration. Thanks to Ulrich
Drepper for this hint.
Comment 1 Daniel Walsh 2006-01-02 12:07:12 EST
Fixed in  selinux-policy-2.1.6-19
Comment 2 David Nielsen 2006-02-24 05:52:39 EST
I'm seeeing this with selinux-policy-2.2.20-1
Comment 3 Mike A. Harris 2006-02-24 06:12:47 EST
If the problem still exists for you, be sure to reopen the bug report
and set it to ASSIGNED state.  "MODIFIED" means that it is fixed and
awaiting testing, and generally wont get looked at anymore unless someone
changes the bug state.
Comment 4 David Nielsen 2006-02-24 06:30:26 EST
I don't own the bug, so I looked hard and I can't reopen the bug in any obvious
way - one of the many reasons why bugzilla is my archenemy
Comment 5 Daniel Walsh 2006-02-24 08:31:18 EST
What is the label on /usr/lib/dri/savage_dri.so
What avc messages are you seeing?
Comment 6 David Nielsen 2006-02-27 07:54:50 EST
type=AVC msg=audit(1141044974.032:4778): avc:  denied  { getattr } for  pid=2151
comm="pam_console_app" name="card0" dev=tmpfs ino=5751
tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file
type=AVC_PATH msg=audit(1141044974.032:4778):  path="/dev/dri/card0"
type=PATH msg=audit(1141044974.032:4778): item=0 name="/dev/dri/card0" flags=0
inode=5751 dev=00:10 mode=020666 ouid=0 ogid=0 rdev=e2:00

-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t i810_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t i830_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t i915_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t mga_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t r128_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t r200_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t radeon_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t savage_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t sis_dri.so
-rwxr-xr-x  root     root     system_u:object_r:textrel_shlib_t unichrome_dri.so

r200 being the relevant driver for me, however the issue appears also under test
with my r300 and r100 based ATI cards.
Comment 7 David Nielsen 2006-02-27 10:56:21 EST
Ah I found the error, I had not properly cleaned out the Xair server - it works
now as it's supposed to.
Comment 8 Mike A. Harris 2006-02-27 19:23:46 EST
The selinux policy should be updated to treat Xair as xserver_exec_t or whatever
it is also.  Assuming it hasn't been already that is. ;)

Comment 9 Daniel Walsh 2006-02-28 06:24:38 EST
/usr/bin/Xair             --     gen_context(system_u:object_r:xserver_exec_t,s0)

Has been in policy for a week now.

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