Graham Leggett wrote:
> Jess M. Holle wrote:
>
>> I also find the current 'httpd-ldap' sub-project status lamentable --
>> though at least at 2.0.40 it builds (but has to be patched to run on
>> Windows!) and includes instructions for making it part of your Apache
>> 2 build process (on UNIX).
>
> That's because all the integration into v2.0 was done by me, and I
> know nothing about windows.
>
> It's up to the windows guys to step forward and fix this, I can't I'm
> afraid, sorry.
I've filed a bug (12091) with a suggested patch included. I've also
attached my previous post of the same code.
The crash is specific to Windows. My change is not, however.
My reading of the code is that the current sources reference
uninitialized memory. On some platforms the results of this can be
rather predictable -- on others they are not. Hence I feel that my fix
may be correct for all platforms and have nothing to do with Windows
other than that that is where the memory reference first had a
disastrous effect.
If you see issues with my suggested patch has issues, let me know. I
have no commit authority or any such, so I believe I've done all I can.
>> Worse, it has scared off the original www.rudedog.org folk from
>> maintaining it -- leaving critical LDAP authentication functionality
>> in limbo.
>
> If it's in an ASF tree then in theory it's ASF supported (which it is,
> there are people here who have committed code). The rudedog guys
> certainly have no obligation to support it, although their involvement
> and experience would be a really good thing.
Understood. I can tell from the CVS history that you and a handful of
others are doing your best. The issue is one of ensuring the
broader-based support, multi-platform involvement, etc, that something
as critical to many corporate intranet deployments as LDAP
authentication support deserves.
--
Jess Holle
--- Begin Message ---
The Apache 2 modules in the httpd-ldap sub-project (which should be moved
into 'experimental' in my opinion and have standard MSVC++ projects created,
etc -- though I have no vote) crash on Windows 2000 in Apache 2.0.40. [Yes,
I'll file a bug as appropriate.]
The issue is use of uninitialized memory in util_ldap_cache_init() [in util_ldap_cache.c].
This routine declares a variable on stack, 'rmm_lock', and passes it to
apr_rmm_init() without initializing it. apr_rmm_init() expects this argument
to be initialized and causes a later crash on Windows as a result of finding
random gargly-gook in this structure and interpretting it in such a way that
does not match the reality of the situation.
My patch (sorry I'm new at this and don't know how to generate proper patches
:-( ) is to no longer declare this variable and pass NULL to apr_rmm_init()
in its place -- as apr_rmm_init() can take a NULL for this argument. This
seems to work fine on Windows and Solaris -- though I can't get this module
to load on AIX (no, I've not yet tried the original code....)
The line are (in patch pseudo-syntax):
Lines 293-297:
apr_status_t util_ldap_cache_init(apr_pool_t *pool, apr_size_t
reqsize)
{
- apr_anylock_t rmm_lock;
#if APR_HAS_SHARED_MEMORY
and lines 305-308:
/* This will create a rmm "handler" to get into the shared
memory area */
- apr_rmm_init(&util_ldap_rmm, &rmm_lock,
+ apr_rmm_init(&util_ldap_rmm, NULL,
(void *)apr_shm_baseaddr_get(util_ldap_shm), reqsize,
pool);
#endif
The only alternative that I see is to add a call to initialize 'rmm_lock',
but from my brief scan it would appear that passing null is a more efficient
way of accomplishing the same thing.
Any comments?
--
Jess Holle
--- End Message ---
