prelink should not mess with running executables
Andrew Haley
aph at redhat.com
Thu Jul 19 11:57:15 UTC 2012
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.
More information about the devel
mailing list