Description of problem: The selinux updates of 3/29 prevent xmame and xmess from running: [andre@localhost ~]$ xmame xmame: error while loading shared libraries: /usr/lib/libglide3.so.3: cannot restore segment prot after reloc: Permission denied [andre@localhost ~]$ xmess xmess: error while loading shared libraries: /usr/lib/libglide3.so.3: cannot restore segment prot after reloc: Permission denied [andre@localhost ~]$ Corresponding messages from dmesg: audit(1143798901.453:368): avc: denied { execmod } for pid=4985 comm="xmame" name="libglide3-v2.so" dev=dm-0 ino=4184328 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1143798903.297:369): avc: denied { execmod } for pid=4986 comm="xmess" name="libglide3-v2.so" dev=dm-0 ino=4184328 scontext=user_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file I don't understand SELinux at all, so I just picked a random SELinix package. Please reassign to the correct component. Version-Release number of selected component (if applicable): selinux-policy-2.2.25-2.fc5 How reproducible: always Steps to Reproduce: 1. Try running xmame or xmess. Actual results: above error messages Expected results: should run without being blocked Additional info: I'm using the latest xmame and xmess from Freshrpms on an i386.
You can fix this problem with a chcon -t textrel_shlib_t /usr/lib/libglide3.so.3 This rule is in the policy but the sort algorithm is broken. But this should be reported as a bug against xmame/xmess whichever owns libglide3.so.3 with this link. http://people.redhat.com/drepper/selinux-mem.html .
BTW What does matchpathcon /usr/lib/libglide3.so.3 show?
Policy looks sane here: # rpm -q selinux-policy-targeted selinux-policy-targeted-2.2.25-2.fc5 # /usr/sbin/matchpathcon /usr/lib/libglide3.so.3 /usr/lib/libglide3.so.3 system_u:object_r:textrel_shlib_t
[andre@localhost ~]$ rpm -qf /usr/lib/libglide3.so.3 Glide3-20050815-3.fc5 This is in Fedora Extras.
Ah, the light dawns. /usr/lib/libglide3.so.3 is a symlink. The real files are named /usr/lib/libglide-v[0-9]*\.so
So is this a Glide3 bug? If so, I'll reassign to that package. (The latest SELinux updates made no difference, BTW.)
Problem still exists with today's updates (selinux-policy-2.2.29-3.fc5 et al.). Repeating the previous question, should I reassign this to Glide3?
Today's selinux updates have broken xmame for me again. To say that I find this annoying is a large understatement. The fix detailed by Daniel Walsh in comment #1 above does work. It's not clear to me why this would be regarded as a bug with xmame/xmess when it appears that selinux is preventing an application from loading a library it needs.
Since I haven't gotten a response, I'm reassigning this bug to Glide3 in Fedora Extras.
How have the updates broken xmame? What avc messages are you seeing? What does matchpathcon /usr/lib//usr/lib/libglide-v1.s0 show? ls -lZ /usr/lib//usr/lib/libglide-* http://people.redhat.com/~drepper/selinux-mem.html Explains what the execmod problem is.
The avc messages are in comment #1. The impression I get from the above responses is that this bug is associated with the Glide3 package, since the SELinux error is associated with a file in this package, but since I never got a response to my question above, I had to just reassign the bug and see what happens. I think that xmame/xmess have been broken ever since FC5 came out. The later SELinux and xmame/xmess updates made no difference (Glide3 has not been updated, though). [andre@localhost ~]$ /usr/sbin/matchpathcon /usr/lib//usr/lib/libglide-v1.s0 /usr/lib//usr/lib/libglide-v1.s0 system_u:object_r:lib_t [andre@localhost ~]$
With today's selinux-policy and selinux-policy-targeted updates (2.2.34-3.fc5), xmame and xmess work again. The following messages appeared during "yum update": /sbin/restorecon reset /usr/lib/libglide3-v3.so context system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t /sbin/restorecon reset /usr/lib/libglide3-v1.so context system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t /sbin/restorecon reset /usr/lib/libglide3-v2.so context system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t /sbin/restorecon reset /usr/lib/libglide3-v5.so context system_u:object_r:lib_t->system_u:object_r:textrel_shlib_t so the SELinux policy apparently now doesn't block these files anymore. I should have left the bug assigned to the selinux-policy packages but I can't reassign it now so am just closing the bug.
I really don't like this tendency to add all kinds of exceptions to the policy to allow broken programs to survive. This only means that the real bugs will never be fixed. As exemplified by the fact that the category of the bug was changed. This is a bug in glide and nowhere else! Fix that damn code. 100% of all critical bugs in RHEL4 are in desktop programs. We cannot be forgiving when it comes the policy affecting desktop apps.
Reopened since Glide3 is not fixed yet. BTW, Sun's JRE also works again now and there were similar exception messages involving the JRE files, so someone needs to tell Sun to fix their code also if it hasn't been done already.
I just got a mail that this bug got assigned to me, without any further explanation. What fun, and how polite! Can someone please explain to me what the problem exactly is? I know a bit about SELinux but not everything there is to no. Currently on my mostly up2date rawhide system I get: -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libglide3-v1.so -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libglide3-v2.so -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libglide3-v3.so -rwxr-xr-x root root system_u:object_r:lib_t /usr/lib/libglide3-v5.so Which would seem to mean that the exception has been removed as Ulrich requested. So that makes for one happy Ulrich and one unhappy me. Since I'm both the current maintainer of the xmame/xmess Glide code and the maintainer of Glide3 in extras one would have thought I would have been bitten by this, but I haven't. Appereantly this problem is only present when the libglide3.so.3.10 symlink points to libglide3-v1.so. (Yes I have SELinux with the targeted policy enabled). Can someone explain to me why a lib would need textrel_shlib_t instead of just plain lib_t and what I can do to fix this? Thanks!
Text relocations are the result of using position dependent code in a DSO or PIE. See http://people.redhat.com/drepper/dsohowto.pdf for explanations of building DSOs. You can hopefully easily determine what is wrong by building the binaries with debug info and then use the eu-findtextrel utility from elfutils. It should point you to the files which either are not compiled with -fpic/-fPIC or which contain assembler code which is position dependent.
I'll take a look, but I'm afraid this is probably in some piece of assembler code and although I'm not afraid at all of touching C-code my asm knowledge is very bad. It has taken me a conciderable amount of time to get Glide3 into any sort of shape at all (I fixed a zillion strict antialiasing warnings amongst other things), and I'm afraid this one is going to be beyond my capabilities. Rescently some applications have shown up in extras which use the following method to work nicely with SELinux: http://fedoraproject.org/wiki/Packaging/SELinux#head-39d41d058c94d09a077ef6e2623b16b9369d87d1 Would this be an acceptable solution? I know _really_ fixing things would be better, but concidering the small amount of people still using / needing Glide3 and the needed effort from my side I would prefer to leave things as is and just fix the SELinux-labels. (The above sortoff assumes that the problem is not just a missing -fPIC, in that case I'll just fix things).
As I already feared this is in the hanf written / profiled timing optimized triangeldraw asm code, of which their are mmx 3dnow and sse versions for 4 different Voodoo chipsets, that is a lott of asm! So I'm going to modify the Glide3 packages to fixup the libglide.so SELinux type itself as described under: http://fedoraproject.org/wiki/Packaging/SELinux#head-39d41d058c94d09a077ef6e2623b16b9369d87d1 Will this work for FC-4, FC-5 and devel? Is this nescesarry for FC-4 ?
I've added the folowing to the specfile, to set to context to textrel_shlib_t on i386 (where the asm gets used). %ifarch %{ix86} Requires(post): policycoreutils /sbin/ldconfig Requires(postun): policycoreutils /sbin/ldconfig %endif %ifarch %{ix86} %post /sbin/ldconfig # Set SELinux file_context in the policy semanage fcontext -a -t textrel_shlib_t '%{_libdir}/libglide3-v.\.so' 2>/dev/nu # Actually change the context chcon -t textrel_shlib_t %{_libdir}/libglide3-v?.so || : %else %post -p /sbin/ldconfig %endif %ifarch %{ix86} %postun /sbin/ldconfig # SELinux support if [ $1 -eq 0 ]; then # final removal semanage fcontext -d -t textrel_shlib_t '%{_libdir}/libglide3-v.\.so' 2>/dev/ fi %else %postun -p /sbin/ldconfig %endif I've tested this on FC-5 i386 and devel x86_64 and it works as expected. This has been comitted to CVS and builds have beenr equested for devel and FC-5.
The latest policyupdate should have these marked as textrel_shlib_t so this is not necessary. Fixing the library is what we need. Until the policy will use textrel_shlib_t. Dan
Erm, I already build this update and it has already been pushed to the mirrors. If I'm not mistaken then these scriplets can't harm even with a policy which doesn't require them anymore, correct? In that case I'm going to leave things as is since I don't want tp ush a needless update. Also I don't plan on fixing the libs, they are really Legacy and although I plan on fixing any real bugs and keep them working with the latest dev chain I'm not planning on doing any additional work. Last note, the textrel_shlib_t is only needed on i386, hence I've made the scriplets conditional on the arch in the spec, did you do the same for the policy? You might concider removing this exception from the policy (assuming the scriptlets work as advertised) since I see little reason for an exception in _the_ policy for a package very few users will install.