httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: apr_dbm funkiness...
Date Wed, 07 Nov 2001 03:28:34 GMT
On Tuesday 06 November 2001 06:38 pm, Bill Stoddard wrote:
> I've discovered an interesting problem with the apr_dbm code (or perhaps
> how SSL is using it).
>
> Consider the following code from ssl_scache_dbm_retrieve()...
>
> if (apr_dbm_open(&dbm, mc->szSessionCacheDataFile,
>     APR_DBM_RWCREATE, SSL_DBM_FILE_MODE, mc->pPool) != APR_SUCCESS) {
>     ssl_log(s, SSL_LOG_ERROR|SSL_ADD_ERRNO,
>             "Cannot open SSLSessionCache DBM file `%s' for reading
> (fetch)", mc->szSessionCacheDataFile);
>     ssl_mutex_off(s);
>      return NULL;
> }
> rc = apr_dbm_fetch(dbm, dbmkey, &dbmval);
> apr_dbm_close()
>
> apr_dbm_fetch() returns dbmval which contains a pointer to the char* value
> associated with the search key. Turns out that this value resides in
> storage allocated during the apr_dbm_open() call.  When apr_dbm_close() is
> called, the value is no longer valid and may be overwritten.
>
> So, either we need to replicate the value in memory with suitable lifetime
> scope (where? in apr_dbm_fetch? would need to pass in a pool to do this).
> Or not issue apr_dbm_close until we are done using the value.
>
> Thoughts?

It should be up to the caller to copy the data.  Basically, after the 
apr_dbm_fetch and before the apr_dbm_close, we should do a memcpy.

Ryan
______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message