prelink should not mess with running executables

Sam Varshavchik mrsam at courier-mta.com
Mon Jul 16 02:20:59 UTC 2012


Chris Adams writes:

> Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
> > Chris Adams writes:
> > >Is there anything that actually does that and depends on the result?
>
> You skipped this part.  Can you name something that tries this?  I bet
> somebody can break it if so.

When the code is ready, I'll name it, certainly, and I'll welcome anyone to  
attempt to break it. But that's just a sideshow. Whether something like this  
can or cannot be broken does not make what prelink does any more or less  
sensible.

Although the problem is easily solved simply either by uninstalling prelink,  
or blacklisting a binary, which is just as easy, this is just sweeping the  
dirt under the rug. I don't think that either one is a productive solution.

I think that 99% of the problems that prelink is creating can be easily  
avoided simply by having prelink automatically skip executables that are  
currently running. This is something that should not be very difficult to  
do. All the information is trivially obtainable from /proc/*/exe.

This would not be perfect, this does have the obvious race conditions, but  
this should solve 99% of the problems that prelink creates, and 99% looks to  
me a whole lot better than nothing.

A 100% solution would be a generalized implementation of the hack in  
prelink's wrapper script that manually reexecs init. This is a fairly  
obvious indication that what prelink is doing is creating a problem for  
init. I do not believe that a convincing argument can be made that what  
prelink is doing is hunky-dory. If it was, /etc/cron.daily/prelink would  
have no reason to care about init or do anything about it. But it does. That  
means that it's creating a problem.

The 100% solution would be the registration mechanism that indivual binaries  
can install, to be invoked by prelink when it scribbles over the binary in  
question, so that the binary can provide whatever needs to be done in order  
to regain its own sanity.

But, the 100% solution is quite a bit of work. Of course, that would be the  
best thing to do; it's just that the 99% fix seems to be a bit more bang for  
the buck, at least.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120715/73d7efbf/attachment.sig>


More information about the devel mailing list