On 03/26/10 04:44 AM, David Schwartz wrote:
Mark Phalan wrote:
The threads(3) manpage states that to use OpenSSL in multi-threaded
applications then locking callback functions must be set otherwise
random crashes may occur.
That is correct.
This poses a challenge when using OpenSSL in a library which should be
MT safe. There is no safe way to set the locking callbacks from within
the library itself. The calling application may or may not be using
OpenSSL or may be linking against multiple libraries some of which may
be linked against OpenSSL. The application may not even be aware that
it
will end up calling into OpenSSL code.
It's trivial -- adopt the same solution OpenSSL adopts. Have the application
set your library's locking callbacks and you pass them onto OpenSSL. It
won't matter then if you change the callbacks because you'd be changing them
to what they already were or would be anyway.
Unfortunately that's not really practical. To take an example I'm
familiar with - libgss. libgss can end up calling into OpenSSL in the
following way:
libgss -> kerberos -> pkinit plugin -> openssl
It's simply not practical to change libkrb5 and libgss and all
applications using those libraries.
The only safe way to ensure that the OpenSSL code will be MT safe would
be for the OpenSSL library itself to set locking callbacks, however I
don't see any compile-time option to do that.
It can't do that, it has no idea what threading model the application is
using. It would have no way to know whether the locks it provided were
suitable or sensible.
Well on Solaris it's most likely going to be using either POSIX threads
or Solaris threads which are interoperable and can be used in the same
application. If an application wants to do something unusual it can set
the callbacks. I'm not suggesting that applications should lose the
power to set locking callbacks.
Having default callbacks will simply mean that applications which don't
use OpenSSL or don't set callbacks will be more likely to work.
Is there a reason I'm missing as to why this option isn't available?
The library has no way to know what threading model the application that
calls it is using. Only the application has this knowledge, so it's the
application's responsibility to pass this to the library.
Without this, the library can do its best to set the locking callbacks
when loaded if they are not set and then remove them when unloaded,
however this will always be inherently racy if there are other parts of
the process using OpenSSL.
I agree. Your library should impose a requirement on any application that
uses it that it inform you of the threading model it's using so that you can
use appropriate locking as well. Then you can set the OpenSSL locking
callbacks (just pass them through) and there's no chance of a race or
problem.
See above. That's simply not practical (the horse has left the stable).
-M
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
