log: Mitigate disk filling attacks by globally rate limiting LogPrintf(…) #21706
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
🕵️ @sipa has been requested to review this pull request as specified in the REVIEWERS file. |
38a3b62 to
21a75de
Compare
|
From ci: test/logging_tests.cpp(78): error: in "logging_tests/rate_limiting": check curr_log_file_size - prev_log_file_size == 1024 * 1024 has failed |
21a75de to
9fbbedf
Compare
|
@dergoegge Thanks for working on this. Would you mind rebasing? I would like to review the updated version :) |
|
Concept ACK While I have a slight preference for the approach taken in #21603 (rate-limiting per log location), but the approach in this PR (rate-limiting globally) works too. Concept ACK on both: the important thing is that we kill this bug class :) |
9fbbedf to
aa6a139
Compare
|
We will move forward with the other approach in #21603. See the PR description there for the reasoning. |
This is an alternative to #21603 in an attempt to solve #21559.
Example for the approach in this PR: Location A logs excessively and logging gets suppressed for up to one hour. All logs from any other location will also be dropped during the suppression period. After ~one hour logging restarts and a message with a report on which locations have been suppressed is printed to the log.
The key difference to #21603 is that logging is suppressed globally instead of "per source location" when at least one source location is logging excessively.
Approach review is probably the best next step to determine which of the two PRs to move forward with.