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

Antw: slap_timestamp with microsecond granularity?



>>> "Paul B. Henson" <henson@acm.org> schrieb am 29.04.2014 um 05:17 in Nachricht
<20140429031735.GC1541@bender.unx.csupomona.edu>:
> 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)?

Here you can see that the C Library has come to ages: stuct tm lacks fractional seconds, nad strftime is based on struct tm.
In a similar problem I used a hybrid approach like this:

                if ( clock_gettime(CLOCK_REALTIME, &ts) == 0 &&
                     localtime_r(&ts.tv_sec, &tm) != NULL &&
                     strftime(time_string, sizeof(time_string),
                              "%Y%m%d %H%M%S.hhtuuunnn", &tm) > 0 )
...
                        fp = time_string + 15;          /* .hhtuuu */
                        ssize_t nsz = 10;
                        rval = snprintf(fp + 1, nsz, "%09ld", ts.tv_nsec);
                        assert(rval < nsz);
...

Ulrich

> 
> 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.
> 
> 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.
> 
> Thanks...