This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients barry, benjamin.peterson, christian.heimes, georg.brandl, neologix, pitrou, python-dev, sbt, vstinner
Date 2013-08-21.14:46:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM1bmgDkyXVLgd7-Q+F57JCMVMj=LVHdeJO9AWHuXkWJSQ@mail.gmail.com>
In-reply-to <244612104.2745072.1377091416489.JavaMail.root@zimbra10-e2.priv.proxad.net>
Content
2013/8/21 Antoine Pitrou <report@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...
History
Date User Action Args
2013-08-21 14:46:08neologixsetrecipients: + neologix, barry, georg.brandl, pitrou, vstinner, christian.heimes, benjamin.peterson, python-dev, sbt
2013-08-21 14:46:08neologixlinkissue18747 messages
2013-08-21 14:46:08neologixcreate