Charles-François Natali added the comment: 2013/8/21 Antoine Pitrou <rep...@bugs.python.org>: > Instead of reseeding in the child, you can perturb the state in the parent > after fork. > As far as I understand, only the "child" callback in pthread_atfork() needs > to be async-signal-safe:
That's not completely true: fork() is supposed to be async-signal safe: it can be called from a signal handler (I wouldn't do this, but that's allowed), but most notably, it can be called after another fork(). For example, let's say you have a multi-threaded process, and it fork()s. If you reseed from "parent" (right before or after fork), then it's safe. But once you're in the child process, the process state is "unsafe" until exec(), i.e. you can only call async-signal safe functions. So if you fork() again before exec() - which is common, e.g. if you use the double-fork() idiom for daemons - then you'll call the reseed in an unsafe context. In other words, the "parent" callback is called in the context of a "child" callback in the child process. So it's not really safe either, although the window is narrower. The only 100% safe way I can think of - apart from ignoring the problem - would be to check if the PID has changed upon entering ssl function (caching it to avoid calling getpid() everytime), keeping in mind that there will still be the risk of deadlock/crash anyway if the user enters the ssl library before exec()... Another, probably cleaner way would be to finally add the atfork() module (issue #16500), and register this reseed hook (which could then be implemented in ssl.py). forking() in a multi-threaded context is an unsolvable problem... ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18747> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
