While porting mod_watch to Apache 2.0, I looked at mod_auth_digest as an example of a module using shared memory and mutexes. While looking at it I found what I would consider to be some serious problems with the code: a) No where in the module is client_rmm initialised before being used. b) Line 1103 has the following: apr_global_mutex_lock(opaque_lock); op = (*opaque_cntr)++; apr_global_mutex_lock(opaque_lock); I think the second apr_global_mutex_lock() should be apr_global_mutex_unlock().
ugh... that isn't the only massive suckage... client_shm is initialized but not used for anything but a flag... in add_client(), a lock is obtained but not released on an error path...
Either we should fix this (ouch, it is soooo broken), or just toss the shmem usage from mod_auth_digest. It's always disabled now. If someone wants to add it back, they would probably be better starting off from scratch than trying to sort out the current mess.
We should just remove the shmem code from head, since it has never been used anyways..
Seems fairly easy, but nothing yet after three years.
Still seems fairly easy, only six years since the problem was opened :-)
Created attachment 23921 [details] Replace use of shared memory with socache Here's a first pass at replacing mod_auth_digest's use of shared memory with socache. The changes are more pervasive than I'd like to make all at once, but the assumptions about use of shared memory went through a lot of the code. Feedback, criticism, suggestions for improvement welcome.
Instead of completely re-writing it, I fixed the shared memory, rmm, and lock usage problems that have been reported or that I came across while fixing those. Fixed in trunk rev 808150
Fixed as far back as anyone is probably willing to go (fixed in trunk before 2.4.x branch)
Also see PR51711 ?
Users applying this patch to earlier 2.0/2.2 sources should be aware of r1773069 correcting CVE-2016-2161 - a defect exposed by enabling shm (which seems to have been effectively impossible before this fix.)