Description of problem: Some sort of linking error, SElinux executable stack sort of problem. Version-Release number of selected component (if applicable): glx-utils-6.4.2-3 How reproducible: always 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.
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 ***