[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slap_timestamp with microsecond granularity?

Since you're talking about changes to actual OpenLDAP code, this discussion belongs in openldap-devel, not openldap-technical.

Paul B. Henson wrote:
Reviewing current time handling code, while lutil_parsetime understands
and can parse a generalized time that includes fractions of a second,
there doesn't seem to be any code that can generate a generalized time
string including fractions of a second, in particular to microsecond
resolution (to match a struct timeval time)?

Clearly such code must exist in the source tree, since entryCSNs use microsecond resolution.

I'd like to enhance the current password policy module to use
microsecond resolution for the pwdFailureTime attribute, as the current
1 second resolution makes it less than ideal for account lockouts.
Currently, it is using slap_timestamp to generate the generalized time
to store, which only provides a generalized time with 1 second
granularity. On initial review, it looks like simply storing a generalized
time with microsecond resolution in the pwdFailureTime attribute is all
that is required to enhance the ppolicy module for better account
lockout support, because as previously mentioned lutil_parsetime already
understands and can parse fractional seconds. I don't see any other code
that would need to be modified so far.

The question is how to generate the needed format? One option would be
to enhance one way or another the existing generic support, perhaps
adding a slap_timestamp_usec function? Another would be to just add a
call to gettimeofday() next to the current call to time() in the ppolicy
code, generate the generalized time string with slap_timestamp, and then
mash the fractional seconds into it.

gettimeofday() only exists on POSIX systems; if you're adding a generic slap_xxx function it has to be portable across Windows and other OSs too.

Ideally I'd like to get this enhancement to ppolicy accepted into the
code base, so I'd appreciate some feedback as to what implementation
would be preferred for this.


  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/