I have just set up a fairly extensive logging and logrotation operation on a system, to hopefully eliminate or at least minimize the risks of out-of-space errors (possible vulnerabilities?).
However, I have not been able to find a definite answer to this question in the manpages for the
How does the logrotate service determine the timestamp of the last logrotation for its daily,weekly or monthly option?
The excerpt from
man logrotate goes as follows:
weekly [weekday] Log files are rotated once each weekday, or if the date is advanced by at least 7 days since the last rotation (while ignoring the exact time). The weekday interpretation is following: 0 means Sunday, 1 means Monday, ..., 6 means Saturday; the special value 7 means each 7 days, irrespectively of weekday. Defaults to 0 if the weekday ar‐ gument is omitted.
Is the time of the last rotation simply checked constantly (using a cronjob) by looking at the last modification timestamp of the previous rotated log file ?
If so, if a user manages to somehow 'fool' the system and force it to de-synchronize its system time (often it is fairly easy to do, because it being a very rare attack vector it is rarely properly guarded ) , consequently having
logrotate create rotated logs with a future timestamp, will that essentially disable
logrotate frequency-based rotation?
For reference: The system in question - because of
tumblerd (whether it was because of the system's configuration, or an actual vulnerability I cannot say) , which is a type of a thumbnail manager from what I understand - was constantly adding entries in
messages logs, reaching up to 100GB each before the system failure (first space-wise, followed by memory leaks and CPU load spikes ). Not only was this a problem in itself but it also made reading these 3 log files impossible, and the only solution I could think of on the spot was
echo "" > [filename] to clear them.