Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
Date: 18 Nov 2003 22:28:39 -0000
Message-ID: <20031118222839.6180.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 24800] New:  -
    Crashes on LDAP authentication on 376th distinct user

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24800>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24800

Crashes on LDAP authentication on 376th distinct user

           Summary: Crashes on LDAP authentication on 376th distinct user
           Product: Apache httpd-2.0
           Version: 2.0.47
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Major
          Priority: Other
         Component: mod_ldap
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: jessh@ptc.com


The following holds true for Apache 2.0.47 on Windows.  It may well hold true 
on other platforms, but I have not done sufficient testing to say for certain.

The out-of-the-box configuration of Apache 2.0.47 crashes upon LDAP 
authentication of the 376th distinct user.  This is with my LDAP URL, search 
filter, etc, so the exact number where the failure will occur will vary.  It 
should be noted, however, that my URLs, user names, etc, are all relatively 
short, so this is not just a pathological case.

I did enough debugging to be all but certain that the cause of this is no 
checks for null results when allocating memory from the LDAP shared memory 
block -- combined with too low of a default value of LDAPSharedCacheSize.

At a minimum the LDAPSharedCacheSize default value should be large enough for 
the default LDAPCacheEntries and LDAPOpCacheEntries and "typical" data in 
each.  Unfortunately nothing is really "typical" and the only real fix is to 
add appropriate result checking and handling of null results.

For those looking to work around this issue, I have found that for *my* data 
each LDAPCacheEntries entry takes around 270 bytes.  [I don't use 
LDAPOpCacheEntries, but I've also discovered that if LDAPCacheEntries is non-
zero LDAPOpCacheEntries must be non-zero or crashes will occur in this case as 
well -- I thus use a value of 1 for LDAPOpCacheEntries.]  I combine this with a 
factor of safety to compute LDAPSharedCacheSize based on my LDAPCacheEntries 
setting.

After all of these efforts I still get crashes when the number of distinct 
users exceeds LDAPCacheEntries , but I'll file a separate bug on that.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org