On 07/19/2012 12:29 PM, Andrew Haley wrote:
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.
Ahh, Jakub corrected this. Sorry for the bad info.
The rest stands, in particular:
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.