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): prelink-0.3.6-1 How reproducible: Always 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 3.Reboot? 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. Additional info:
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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.