Red Hat Bugzilla – Bug 169985
prelink aborts in prelink_save_cache
Last modified: 2008-04-05 03:06:51 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8b4) Gecko/20050915 Fedora/1.5-0.5.0.beta1 Firefox/1.4
Description of problem:
If selinux mcs is enabled after an install that predates mcs, the kernel starts demanding :s0 suffixes in selinux.context. Since prelink doesn't add them (and IMHO it should not, this transparency failure in mcs's implementation is addressed in a separate bug), the setxattr calls that attempt to apply to the new prelinked file the same context that the original file had fail.
When this occurs, prelink will sometimes crash at the end, while saving the new cache file. It doesn't happen every time some setxattr call files, but if it happens for a prelink -av -mR -q, it will happen until you fix at least some of the contexts. Unfortunately, I haven't been able to figure out the exact conditions in which the failure occurs.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Install an old FC devel tree, or even FC4.
2.Update to FC devel, bringing in libsetrans and mcs enabled by default
4.Let prelink run
Actual Results: Prelink will most likely crash, since pretty much every file will be incorrectly labeled and be in need of prelinking
Expected Results: It's ok that prelink fails because it can't propagate contexts (this should be fixed elsewhere IMHO), but it's not ok that it crashes.
Might be related to libselinux.a not dlopening libsetrans.so (but that's
something we asked for, having statically linked binaries dlopen some lib
is a bad idea).
Anyway, can you please install prelink-debuginfo and get a backtrace for me?
Erhm... I actually ran the thing within a debugger, back then, and the stack
trace did not make it seem like the problem had been triggered at that point,
but rather at a much earlier time, and that the crash at that point was just a
symptom of the earlier problem. I didn't investigate it further, and the
problem went away as I relabeled all of my filesystem. I don't know how to
trigger the problem any more, but I'm pretty sure it's still there.
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
This is probably related with another prelink cache save bug I helped fix a long
time ago. I haven't run into this problem any more, and I don't quite see how
to, so I'll close this as a WORKSFORME.