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. >> 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. Maybe we can fix the man page then. > And it works every time. Until prelink overwrites the executable. But that's just the point: until something 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. Perhaps so. At best it's only the path to the executable that started the program. >> 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, The root cause is the filesystem behaviour of UNIX that allows a program to continue even though its executable file has been rewritten. That's a feature, not a bug, and it's what allows updating to be done without restarting. > and blaming something else, which exposes the problem. 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
