https://bz.apache.org/bugzilla/show_bug.cgi?id=66355
Bug ID: 66355
Summary: Wrong unit for LDAP/LDAPRetryDelay
Product: Apache httpd-2
Version: 2.4.54
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: mod_auth_ldap
Assignee: bugs@httpd.apache.org
Reporter: smblott@gmail.com
Target Milestone: ---
The documentation suggests `LDAPRetryDelay` is in seconds.
The code appears to treat it as microseconds.
The effect is that Apache sometimes issues rapid bursts of almost simultaneous
LDAP search/bind requests.
The bug fix is simply to replace
apr_sleep(st->retry_delay);
with
apr_sleep(apr_time_from_sec(st->retry_delay));
(httpd/modules/ldap/util_ldap.c:668).
Here's my research:
Issue:
LDAP configuration option LDAPRetryDelay...
The Documentation suggests that the unit is seconds:
https://httpd.apache.org/docs/2.4/mod/mod_ldap.html#ldapretrydelay
The code suggests that the unit is microseconds (see code chase, below).
Effect:
Apache sometimes issues a burst of almost simultaneous LDAP requests.
(In my organisation, this is "catastrophic" since, if the password is
incorrect, it appears as N failed login attempts, and the account is
instantly blocked (after just a single attempt). In practice,
I've observed N in the region of 5 to 7.)
Configuration option:
LDAPRetryDelay 5 (for example)
This sets the retry delay for LDAP connections.
In the code, this ends up here...
In util_ldap_set_retry_delay (util_ldap.c:2859):
st->retry_delay = timeout;
Note... no unit conversion takes place; the code just checks that it's
a non-negative integer and notes the value for later.
The delay is implemented in httpd/modules/ldap/util_ldap.c:668:
apr_sleep(st->retry_delay);
Note... we still appear to have the raw value from the configuration
file (nominally in seconds).
If you search the code, you will find that apr_sleep is ALMOST ALWAYS
called like this:
apr_sleep(apr_time_from_sec(XXXX))
That is, the unit expected is whatever is returned by apr_time_from_sec().
In APR, apr_time_from_sec() is defined like this (apr/include/apr_time.h):
/** number of microseconds per second */
#define APR_USEC_PER_SEC APR_TIME_C(1000000)
.
.
.
/** @return seconds as an apr_time_t */
#define apr_time_from_sec(sec) ((apr_time_t)(sec) * APR_USEC_PER_SEC)
So, the result of apr_time_from_sec is in microseconds.
So the call in util_ldap.c needs to be fixed (as stated at the top).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org
Bug ID: 66355
Summary: Wrong unit for LDAP/LDAPRetryDelay
Product: Apache httpd-2
Version: 2.4.54
Hardware: PC
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: mod_auth_ldap
Assignee: bugs@httpd.apache.org
Reporter: smblott@gmail.com
Target Milestone: ---
The documentation suggests `LDAPRetryDelay` is in seconds.
The code appears to treat it as microseconds.
The effect is that Apache sometimes issues rapid bursts of almost simultaneous
LDAP search/bind requests.
The bug fix is simply to replace
apr_sleep(st->retry_delay);
with
apr_sleep(apr_time_from_sec(st->retry_delay));
(httpd/modules/ldap/util_ldap.c:668).
Here's my research:
Issue:
LDAP configuration option LDAPRetryDelay...
The Documentation suggests that the unit is seconds:
https://httpd.apache.org/docs/2.4/mod/mod_ldap.html#ldapretrydelay
The code suggests that the unit is microseconds (see code chase, below).
Effect:
Apache sometimes issues a burst of almost simultaneous LDAP requests.
(In my organisation, this is "catastrophic" since, if the password is
incorrect, it appears as N failed login attempts, and the account is
instantly blocked (after just a single attempt). In practice,
I've observed N in the region of 5 to 7.)
Configuration option:
LDAPRetryDelay 5 (for example)
This sets the retry delay for LDAP connections.
In the code, this ends up here...
In util_ldap_set_retry_delay (util_ldap.c:2859):
st->retry_delay = timeout;
Note... no unit conversion takes place; the code just checks that it's
a non-negative integer and notes the value for later.
The delay is implemented in httpd/modules/ldap/util_ldap.c:668:
apr_sleep(st->retry_delay);
Note... we still appear to have the raw value from the configuration
file (nominally in seconds).
If you search the code, you will find that apr_sleep is ALMOST ALWAYS
called like this:
apr_sleep(apr_time_from_sec(XXXX))
That is, the unit expected is whatever is returned by apr_time_from_sec().
In APR, apr_time_from_sec() is defined like this (apr/include/apr_time.h):
/** number of microseconds per second */
#define APR_USEC_PER_SEC APR_TIME_C(1000000)
.
.
.
/** @return seconds as an apr_time_t */
#define apr_time_from_sec(sec) ((apr_time_t)(sec) * APR_USEC_PER_SEC)
So, the result of apr_time_from_sec is in microseconds.
So the call in util_ldap.c needs to be fixed (as stated at the top).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org