On 03/30/10 09:16 PM, David Schwartz wrote:

Mark Phalan wrote:

In this case, I presume 'pkinit' only supports one threading model
(or one
set of compatible threading models). So it can set the callbacks.

It can set the callbacks but it can't set them in a way which is safe
from races.

It can set them before it performs any OpenSSL operations. How is that not
safe from races?

I think Darryl answered that.



Then set default callbacks in your code that calls OpenSSL. OpenSSL
can't do
it, because it has no idea what threading models your code uses.

Perhaps I don't understand exactly what you mean by "threading model".
Are you referring to 1:1, n:1 etc?

That's part of it. It's also what threading library you are using.

I think it would be reasonable for OpenSSL as delivered with an OS to
use the native threading model of the OS. Is there something I'm
missing?

If you only support one threading model, there's no problem. Just set
callbacks that are safe for that threading model before you use OpenSSL.


(Speaking as someone who cares mostly about OpenSolaris)
I think the special-case here is when someone decides not to use the OS threading model. In that case the application can simple set the callbacks replacing the ones automatically set.

...
Just to be totally clear. All I'd like to see is a compile-time option
(it can be disabled by default) to set a default set of locking
callbacks native to the OS it's compiling on. I'm not suggesting that
the ability to set locking callbacks be removed.

If you are able to craft a default set of locking callbacks that are safe
for your application, then do so and set them. I don't see what assistance
you need from OpenSSL. If that is your case, your solution is trivial -- set
those callbacks. If you know they're safe, set them.

I see no problem with applications. The problem only arises with libraries linking against OpenSSL, especially when they are dlopen'ed and the application isn't even aware of that that is happening and the application isn't already using OpenSSL.

To use an example a colleague pointed out to me recently:
Application calls getpwnam()
    getpwnam -> nsswitch -> dlopen nsswitch_ldap ->
        ldap uses SSL -> libssl
        ldap uses SASL ->
            libsasl -> GSS-API
                libgss -> Kerberos
                    dlopen mech_krb ->  dlopen pkinit
                        pkinit -> OpenSSL libcrypto

..

There is only a race if some application either reverts to no callbacks or
sets unsafe callbacks. Both of those operations will still be fatal with the
suggested change.

Imagine the above case happening in one thread while another thread makes a similar seemingly innocuous call with a similar effect (dlopen a library which uses OpenSSL). What should pkinit and the second library which uses OpenSSL do? If they set callbacks they'll be racing against each other. If they don't they will not be MT safe. The application never sets the callbacks because as far as it's aware it's only calling POSIX APIs.

-M
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           majord...@openssl.org

Reply via email to