httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 31898] - Potential crash in util_ldap_cache_checkuserid
Date Thu, 28 Oct 2004 15:30:35 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31898>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=31898

Potential crash in util_ldap_cache_checkuserid





------- Additional Comments From bnicholes@apache.org  2004-10-28 15:30 -------
That's my point.  The only way for any ldap_auth module that is built on top 
of util_ldap to add a user ID/password to the cache is through the 
util_ldap_cache_checkuserid() API.  By applying the above patch, adding a null 
password to the cache for a user ID is no longer possible through 
util_ldap_cache_checkuserid() and therefore not possible at all.

The duplicate search on line 945 is there to handle multi-threaded race 
conditions especially on MP boxes.  The only way that a userID/password entry 
can be added to the cache is after passing through the following process.  

1. Does the userID/password entry already exist in the cache? -> no
2. Does the user object exist in the directory? -> yes
3. Can we successfully bind to ldap using the userID/password? -> yes
4. Does the userID/password entry exist *now* in the cache? -> no
5. Add the userID/password entry to the cache.

The reason for step #4 is to make sure that some other thread following the 
same procedure with the same userID/password entry, didn't hit step #5 while 
the first thread was still in steps #2 or #3.  So the only way that the same 
userID with 2 different passwords could successfully make it into the cache is 
if the user successfully logged into an auth_ldap protected page, then quickly 
changed his ldap password and then successfully logged in again within the 
configurable expiration period.  Then for the remainder of the expiration 
period, the cache would be out of sync with the LDAP directory.  Once the 
expiration period has passed for the invalid entry, that entry will be removed 
from the cache and the cache will be back in sync with the LDAP directory.  

So the key is, what is a reasonable userID/password expiration period. The 
default is 600 seconds (10 minutes) which could be enough time to allow the 
described situation to occur.  So if that is something that appears to be a 
problem, drop it to 60 or 30 seconds.  The purpose of the ldap cache is to 
increase performance when displaying protected web pages that might require 
multiple requests to complete.  Each request requiring a login.  The cache 
simply avoids multiple unnecessary logins.  By dropping it to 30 seconds or 
less (most pages should load in 30 seconds or less, if they don't then ldap 
performance doesn't matter anyway) a cached userID/password would basically be 
good for a single page request.  Subsequent page requests would find an 
expired entry, remove it and recache the new entry.

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


Mime
View raw message