Bug 191191

Summary: libGL.so needs execmod priviliges on load
Product: [Fedora] Fedora Reporter: Noa Resare <noa>
Component: mesaAssignee: Adam Jackson <ajax>
Status: CLOSED DUPLICATE QA Contact: X/OpenGL Maintenance List <xgl-maint>
Severity: low Docs Contact:
Priority: medium    
Version: 5CC: rhbugs
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-06-23 21:13:42 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 Noa Resare 2006-05-09 17:38:31 UTC
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

Comment 1 Hans Ulrich Niedermann 2006-06-18 19:41:00 UTC
FWIW, this problem also exists in stock FC5 (updated using "yum update"),
without any proprietary video drivers or other obscure code.

Comment 2 Adam Jackson 2006-06-23 21:13:42 UTC

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