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.
Attachment:
pgpLktiHHszfz.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
