prelink should not mess with running executables

[Andrew Haley]

On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
> Andrew Haley writes:
> 
>> On 07/18/2012 12:06 PM, Sam Varshavchik wrote:
>>>>
>>>> But that's not a use case.  There's no way to know why you want to do
>>>> this: why you care that another process is running the exact same
>>>> executable.
>>>
>>> Because that's the only process I want to talk to. A form of  
>> authentication,
>>> which I already explained. More than once.
>>
>> You have _claimed_ that it's a form of authentication, but you've produced
>> no reason to believe that it is.  How do you know that the exact same
>> binary isn't running as some rogue user, with other data injected into it?
> 
> 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.

> It's mathematically possible, you know. Any authentication
> mechanism, short of a mind ray-beam implementation over the
> Internet, can be defeated. It's only a matter of how much resources
> are required. Even if some particular approach is not 100% NSA-grade
> bulletproof, it does not mean that it's worthless. I reject that
> claim.
> 
> And this is just another feeble attempt to change the topic. The
> degree to which this kind of authentication is or isn't reliable, is
> completely irrelevant and has no bearing on the problem that prelink
> is creating, by rewriting executables which are currently
> running. That, I believe, can be evaluated on its own merits.

Indeed it can.

> 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?

> That's a defacto acknowledgement that prelink is broken, and this is
> just a lame, pathetic coverup for one of the breaks.

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
isn't, it never has been, and it never will be.  And this is true
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.

Andrew.