Bug 182380
| Summary: | glxinfo throws error loading libGL.so | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Morris <jmorris> |
| Component: | mesa | Assignee: | X/OpenGL Maintenance List <xgl-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | X/OpenGL Maintenance List <xgl-maint> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | drepper, dwalsh, toby |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-03-07 12:13:21 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
John Morris
2006-02-22 02:47:11 UTC
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. |