Bug 187484 - SELinux prevents xmame and xmess from running
Summary: SELinux prevents xmame and xmess from running
Alias: None
Product: Fedora
Classification: Fedora
Component: Glide3
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-31 09:53 UTC by Andre Robatino
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Clone Of:
Last Closed: 2006-04-28 09:26:42 UTC

Attachments (Terms of Use)

Description Andre Robatino 2006-03-31 09:53:37 UTC
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
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

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):

How reproducible:

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.

Comment 1 Daniel Walsh 2006-03-31 14:40:57 UTC
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.


Comment 2 Daniel Walsh 2006-03-31 15:21:44 UTC
BTW What does 
matchpathcon /usr/lib/libglide3.so.3


Comment 3 Stephen Smalley 2006-03-31 15:59:26 UTC
Policy looks sane here:

# rpm -q selinux-policy-targeted

# /usr/sbin/matchpathcon /usr/lib/libglide3.so.3
/usr/lib/libglide3.so.3 system_u:object_r:textrel_shlib_t

Comment 4 Andre Robatino 2006-03-31 20:13:14 UTC
[andre@localhost ~]$ rpm -qf /usr/lib/libglide3.so.3

  This is in Fedora Extras.

Comment 5 Stephen Smalley 2006-03-31 20:32:25 UTC
Ah, the light dawns.  /usr/lib/libglide3.so.3 is a symlink.
The real files are named /usr/lib/libglide-v[0-9]*\.so

Comment 6 Andre Robatino 2006-04-04 21:10:31 UTC
  So is this a Glide3 bug?  If so, I'll reassign to that package.  (The latest
SELinux updates made no difference, BTW.)

Comment 7 Andre Robatino 2006-04-12 00:02:49 UTC
  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?

Comment 8 Robert Morrison 2006-04-12 15:12:28 UTC
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.

Comment 9 Andre Robatino 2006-04-19 06:19:09 UTC
  Since I haven't gotten a response, I'm reassigning this bug to Glide3 in
Fedora Extras.

Comment 10 Daniel Walsh 2006-04-19 16:42:50 UTC
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-*

Explains what the execmod problem is.

Comment 11 Andre Robatino 2006-04-19 16:52:28 UTC
  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 ~]$

Comment 12 Andre Robatino 2006-04-26 20:51:38 UTC
  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
/sbin/restorecon reset /usr/lib/libglide3-v1.so context
/sbin/restorecon reset /usr/lib/libglide3-v2.so context
/sbin/restorecon reset /usr/lib/libglide3-v5.so context

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.

Comment 13 Ulrich Drepper 2006-04-26 21:00:10 UTC
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

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.

Comment 14 Andre Robatino 2006-04-26 21:08:15 UTC
  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.

Comment 15 Hans de Goede 2006-04-27 17:56:41 UTC
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         
-rwxr-xr-x  root     root     system_u:object_r:lib_t         
-rwxr-xr-x  root     root     system_u:object_r:lib_t         
-rwxr-xr-x  root     root     system_u:object_r:lib_t         

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!

Comment 16 Ulrich Drepper 2006-04-27 19:39:26 UTC
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.

Comment 17 Hans de Goede 2006-04-27 19:49:12 UTC
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:

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).

Comment 18 Hans de Goede 2006-04-27 22:48:13 UTC
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:

Will this work for FC-4, FC-5 and devel? Is this nescesarry for FC-4 ?

Comment 19 Hans de Goede 2006-04-28 09:26:42 UTC
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

%ifarch %{ix86}
# 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 || :
%post -p /sbin/ldconfig

%ifarch %{ix86}
# SELinux support
if [ $1 -eq 0 ]; then  # final removal
  semanage fcontext -d -t textrel_shlib_t '%{_libdir}/libglide3-v.\.so' 2>/dev/
%postun -p /sbin/ldconfig 

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.

Comment 20 Daniel Walsh 2006-05-01 20:13:12 UTC
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


Comment 21 Hans de Goede 2006-05-01 20:27:20 UTC

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.

Note You need to log in before you can comment on or make changes to this bug.