Description of problem:
Some sort of linking error, SElinux executable stack sort of problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Pop open a terminal
2. type glxinfo
glxinfo: error while loading shared library: libGL.so.1: cannot enable
executable stack as shared object required: Permission denied
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.)
Machine is a Athlon64 running the Xen kernel with SElinux in the default setting.
Ok, followup time. Disable SELinux and boot the normal kernel and 3D works.
Just disabling SELinux doesn't solve it.
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.
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?
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.
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.
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.
I don't seem to have the glxinfo command installed, but I can confirm the
screensaver issue in Comment #6.
*** This bug has been marked as a duplicate of 178262 ***