Bug 182380 - glxinfo throws error loading libGL.so
Summary: glxinfo throws error loading libGL.so
Status: CLOSED DUPLICATE of bug 178262
Alias: None
Product: Fedora
Classification: Fedora
Component: mesa
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: X/OpenGL Maintenance List
Depends On:
TreeView+ depends on / blocked
Reported: 2006-02-22 02:47 UTC by John Morris
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2006-03-07 12:13:21 UTC

Attachments (Terms of Use)

Description John Morris 2006-02-22 02:47:11 UTC
Description of problem:

Some sort of linking error, SElinux executable stack sort of problem.

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


How reproducible:

Steps to Reproduce:
1. Pop open a terminal
2. type glxinfo
Actual results:

glxinfo: error while loading shared library: libGL.so.1: cannot enable
executable stack as shared object required: Permission denied

Expected results:

Information as to whether hardware GL is enabled.  (Using a Radeon 9250, wanted
to see if FC5 was going to enable the Free hardware GL.)

Additional Info:

Machine is a Athlon64 running the Xen kernel with SElinux in the default setting.

Comment 1 John Morris 2006-02-22 04:38:26 UTC
Ok, followup time.  Disable SELinux and boot the normal kernel and 3D works. 
Just disabling SELinux doesn't solve it.

Comment 3 Daniel Walsh 2006-02-25 20:41:03 UTC
xserver in latest policy should be allow execstack.  

If general userspace needs it you can set the boolean 

setsebool -P allow_execstack=1

To allow it.

You could set the context on the application as xserver_exec_t and that should
also eliminate the problem.

Comment 4 Mike A. Harris 2006-02-25 22:10:51 UTC
The X server doesn't need execstack though.  It uses dlopen() to load its
modules now, and to the best of my knowledge does not currently require an
executable stack.  If we've got things set to allow executable stack for the
X server, we should probably disable it as it should not be needed.

It's the libGL that needs execstack.  It is not linked into the X server,
but rather into the applications themselves.  So every single application
that links to libGL and tries to run under SElinux currently fails.

Currently, people are just adding "selinux=0" to their kernel commandline
to work around the problem, or some other equivalent solution.

What about a libGL_t that allows execstack?

Comment 5 Daniel Walsh 2006-02-27 22:34:59 UTC
Please tell them to set the boolean rather then turn off selinux.

Is there a chance to fix libGL?  

The problem is that the execmem is based on the process not the module.  So our
ownly choice is to confined the applications that run with libgl.

Comment 6 Toby Ovod-Everett 2006-03-05 16:43:05 UTC
Another application that raises the same libGL issue is the KDE Screen Saver.  
I'm running FC5 Test 3 x86_64 and the same libGL.so.1 error is raised when I 
attempt to enable the screensaver from "Configure Desktop..." off of the 
desktop right-mouse button menu.

This may also be the root cause of Bug 183002.

The KDE Screen Saver is a fairly high-profile application, and if there is no 
way to fix libGL between now and release, I would seriously consider adjusting 
the SELinux policies for the screen saver apps.  I don't know very much about 
KDE or SELinux, but it may be worth keep in mind that there may be several ways 
of getting to the screen savers, to the configuration for them, etc., all of 
which may use different executable names and thus require separate entries in 
the SELinux policies.

Comment 7 Toby Ovod-Everett 2006-03-05 22:08:03 UTC
I ran yum update and let it update hundreds of packages and the screensaver 
problem has now resolved itself.  The OpenGL Screen Savers don't appear to 
work, but the other ones display and appear to work.

Comment 8 anshul nigham 2006-03-06 07:55:38 UTC
I don't seem to have the glxinfo command installed, but I can confirm the
screensaver issue in Comment #6.

Comment 9 Mike A. Harris 2006-03-07 12:13:21 UTC

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

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