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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
