httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darryl Miles <darryl-mailingli...@netbauds.net>
Subject Re: Creating a thread safe module and the problem of calling of 'CRYPTO_set_locking_callback' twice!
Date Mon, 11 Dec 2006 18:03:27 GMT
William A. Rowe, Jr. wrote:
> Darryl Miles wrote:
>> Your thinking is correct there is a problem.  Those OpenSSL functions
>> are not documented in my man page but exist in the library.  Yes there
>> is a read-test-write race window by using those APIs alone.
> 
> Nope.  This is set when the server process is running in single process,
> single thread mode, long before the server 'opens up' and spawns off it's
> worker threads.

Understood on the single thread situation.  But what about module 
initialization order guaranteed and possible future modules which may 
also use OpenSSL ?


The goal is to ensure the CRYPTO_xxxx() init functions are called, and 
called exactly once before openssl first use only when openssl is being 
used.

* mod_core (no mod_ssl, no mod_frank, no need do anything no openssl users)
* mod_core + mod_ssl (no mod_frank)
* mod_core + mod_frank (no mod_ssl)
* mod_core + mod_ssl + mod_frank
* mod_core + mod_frank + mod_ssl (opposite initialization order)

There may not be worker threads and apache-http may not support dynamic 
runtime loading / unloading of modules (at this time) but its possible 
to deal with all those concerns cleanly.


> What I DO agree with is that these callbacks should be locked in much
> earlier than post_config.
> 
> I'm happy to see these callbacks locked in at the time we register the
> module itself.

Is the module registration order the same for a given canonical 
configuration (i.e. its not subject to httpd.conf config LoadModule 
directive ordering).

Also can one module can ask the core what other modules are loaded and 
it can ask them if they too are users of OpenSSL.  I.e. whatever system 
to address this problem is used would need to deal with the possible 
existence of a future mod_frank_v2 (that does not exist today but may do 
in the future) in a way that mod_ssl does not need to be recompiled or 
upgraded to know about mod_frank_v2 when the time comes to release 
mod_frank_v2.


Darryl

Mime
View raw message