prelink should not mess with running executables

Andrew Haley aph at redhat.com
Thu Jul 19 11:29:04 UTC 2012


On 07/19/2012 12:10 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
> 
>> On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
>>>
>>> How do you know that the server that gave you a seemingly verified SSL
>>> certificate, that checks out, isn't an impostor that managed to crack the
>>> right prime.
>>
>> Because we know that to do that is at the present, time
>> computationally intractable.  So, it's very unlikely that it's
>> happened unless your opponent is prepared to spend huge resources on
>> you.
> 
> But it's not impossible.

No, and neither is it impossible that your computer will turn into a
bowl of petunias.

> Same thing here. It is "very unlikely" that /proc/pid/exe gives you
> the pathname that was used to start the executable.  But just
> because there are marginal situations where it might not work does
> not invalidate its value-added benefits.
> 
>>> If what prelink is doing is hunky-dory, then why is it that its
>>> wrapper has special-case band-aid init?
>>
>> What's a special-case band-aid about it?  It looks perfectly
>> reasonable to me.  Why wouldn't you restart init?
> 
> Why would you?  If there's nothing wrong with with overwriting an
> executable, and, after all, that's how UNIX worked forever, then why
> bother restarting init?

Hmm, isn't this to make sure that init is using the current libraries
and not holding open the old ones forever?  Sounds perfectly
reasonable to me.

>> But this is nothing to do with prelink.  It's to do with your totally
>> bogus assumption that /proc/self/exe is a reliable way to get the
>> binary image of the executable that started current process.  It
> 
> Well, that's only what proc(5) says it is.

Maybe we can fix the man page then.

> And it works every time. Until prelink overwrites the executable.

But that's just the point: until something overwrites the executable.

>> isn't, it never has been, and it never will be.  And this is true
> 
> If the contents of the /proc/self/exe symlink are something random
> and unrelated, then I think that proc(5) needs to be updated to
> reflect that.

Perhaps so.  At best it's only the path to the executable that started
the program.

>> not just because of prelink; even without prelink you'll still have
>> to be able to cope with this situation.
>>
>> The basic principle of robust programming is that you must expect the
>> unlikely and treat it as normal.  This is a classic case of that
>> principle.
> 
> No, this is a classic case of denying the problem's root cause,

The root cause is the filesystem behaviour of UNIX that allows a
program to continue even though its executable file has been
rewritten.  That's a feature, not a bug, and it's what allows updating
to be done without restarting.

> and blaming something else, which exposes the problem.

You have a clear choice.  You can either write a robust program that
can continue to run in the presence of prelink, updates, and anything
else that might change its executable, or you can continue to blame
the OS and have a program that is not robust.  Your call.

Andrew.


More information about the devel mailing list