homed: ignore ratelimiting counters when timestamp is from future

This likely indicates that the system clock is simply wrong, hence allow
access in this case.

Fixes: #15917
This commit is contained in:
Lennart Poettering 2020-09-02 16:36:27 +02:00
parent 51a95db6dc
commit 61a29a020c
2 changed files with 11 additions and 4 deletions

View File

@ -1295,10 +1295,12 @@ int user_record_ratelimit(UserRecord *h) {
usec = now(CLOCK_REALTIME);
if (h->ratelimit_begin_usec != UINT64_MAX && h->ratelimit_begin_usec > usec)
/* Hmm, time is running backwards? Say no! */
return 0;
else if (h->ratelimit_begin_usec == UINT64_MAX ||
if (h->ratelimit_begin_usec != UINT64_MAX && h->ratelimit_begin_usec > usec) {
/* Hmm, start-time is after the current time? If so, the RTC most likely doesn't work. */
new_ratelimit_begin_usec = usec;
new_ratelimit_count = 1;
log_debug("Rate limit timestamp is in the future, assuming incorrect system clock, resetting limit.");
} else if (h->ratelimit_begin_usec == UINT64_MAX ||
usec_add(h->ratelimit_begin_usec, user_record_ratelimit_interval_usec(h)) <= usec) {
/* Fresh start */
new_ratelimit_begin_usec = usec;

View File

@ -1919,6 +1919,11 @@ uint64_t user_record_ratelimit_next_try(UserRecord *h) {
h->ratelimit_count == UINT64_MAX)
return UINT64_MAX;
if (h->ratelimit_begin_usec > now(CLOCK_REALTIME)) /* If the ratelimit time is in the future, then
* the local clock is probably incorrect. Let's
* not refuse login then. */
return UINT64_MAX;
if (h->ratelimit_count < user_record_ratelimit_burst(h))
return 0;