prelink should not mess with running executables

[Sam Varshavchik]

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

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

Well, that's only what proc(5) says it is. And it works every time. Until  
prelink 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.

> 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, and blaming  
something else, which exposes the problem.

The iphone does not have an antenna problem, people are just holding it  
wrong.

-------------- 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/20120719/c0c2f8bf/attachment.sig>