Description of problem: In some cases selinux denies the "execmod" privilege. For some reason libGL.so does operations that need this privilege on library load. Is it really needed? The reason I'm asking is that it looks like ATI uses mesa as a part of their proprietary driver and they place their shared libraries in subdirectory to /usr/lib which is (was) not previously added to the selinux policy. This lead to selinux permission failures outlined in #191054 Version-Release number of selected component (if applicable): mesa-libGL-6.4.2-6 How reproducible: always Steps to Reproduce: # mkdir /usr/lib/test # cp /usr/lib/libGL.so.1.2 /usr/lib/test # echo "/usr/lib/test" >> /etc/ld.so.conf.d/test # /sbin/ldconfig # ldd /usr/bin/metacity |grep GL.so libGL.so.1 => /usr/lib/test/libGL.so.1 (0x06276000) # /usr/bin/metacity Actual results: /usr/bin/metacity: error while loading shared libraries: /usr/lib/test/libGL.so.1: cannot restore segment prot after reloc: Permission denied Expected results: started metacity Additional info: http://people.redhat.com/~drepper/selinux-mem.html outlines how the need for this privilege can be avoided
FWIW, this problem also exists in stock FC5 (updated using "yum update"), without any proprietary video drivers or other obscure code.
*** This bug has been marked as a duplicate of 178262 ***