libcurl calls 'fork' and 'waitpid' in only one case: to run the helper app
in the newly-added NTLM_SSO authentication method. But, forking in a library
is somewhat dangerous as it can interfere with the parent application's
handling of signals.

Here's one failure scenario: an application can install a signal
handler for SIGCHLD that just calls wait() and throws away the response
code. This is sufficient to avoid zombies and a common approach in
applications that fork. But, applications that do this and use NTLM_SSO
can face disaster. Once the NTLM_SSO helper application exits, a SIGCHLD
signal is sent and the application reaps it with wait(). libcurl
then calls waitpid() on that process ID to reap it itself. Since that has
already been done by the app itself, waitpid() will normally error out
benignly and everyone stays happy. But on a loaded system with many
processes, this opens a race condition whereby waitpid() actually reaps
a *different* process that has reused the PID of the NTLM_SSO helper.
There's been a discussion around this recently on the Busybox list:
http://lists.busybox.net/pipermail/busybox/2011-August/076507.html

Another failure scenario is due to CURLOPT_NOSIGNAL not being respected,
which can cause problems in multithreaded programs, among others.
There's no way to cause libcurl's fork() to avoid raising a SIGCHLD on
exit without changing the global state.

It would be nice to have a solution for this before the next libcurl
release, since that will be the first one with NTLM_SSO support. But, if
not, these issues should at least be documented so application writers can
be aware.

>>> Dan
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-08-26