Description of problem: [...] Prelinking /usr/lib/libgnomesupport.so.0.0.0 /usr/sbin/prelink: cannot get security context for /usr/lib/libgnomesupport.so.0.0.0 : No data available prelink: dso.c:1624: close_dso: Assertion `dso->temp_filename != ((void *)0)' failed. Version-Release number of selected component (if applicable): prelink-0.3.0-16.sel How reproducible: 100% Steps to Reproduce: 1. Run prelink, or wait until it runs from cron. 2. See /var/log/prelink.log. See attached gdb run.
Created attachment 96429 [details] typescript of gdb session
This is on kernel 2.6.0-0.test11.1.9.
0.3.0-15 does not give an assertion failure (but it also fails to prelink anything due to lack of security contexts).
Created attachment 96430 [details] /var/log/prelink.log after a prelink-0.3.0-15 run
Created attachment 96431 [details] /var/log/prelink.log after a prelink-0.3.0-15 run (oops, wrong file last time)
Dan, your patch is certainly buggy in the error path handling (it can do double free etc.). Please look at prelink-0.3.0-15 in dist-fc2 where is some selinux stuff already incorporated. The main thing is that neither of these is right. What prelink should do is around creating of the temporary files use some very minimal setfscreatecon which will allow it only to write the file into the system directories, but they even shouldn't be executable at all, etc. Then, after the file is actually written fully, right before rename, it should be given the desired security context copied from the origin I haven't implemented this because I have no idea how to create such context.
I have redone the patch in prelink-0.3.0-16.sel on Nov 19th. Could you check out this patch. Dan
That's the patch I was talking about. The abort Tim got was from 16.sel. Now, when Tim has SELinux capable kernel, what are the reasons why could getfilecon fail (with ENODATA)? Shoudl that be always considered as fatal thing? If you tell me how the very little priviledged context can be created, I'll update prelink.
Please try prelink-0.3.0-17 in dist-fc2-scratch.
0.3.0-17 works fine.