<div dir="ltr"><div dir="ltr">On Thu, 13 Aug 2020 at 13:18, Axel Beckert <<a href="mailto:abe@deuxchevaux.org">abe@deuxchevaux.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
at least in Xymon 4.2.28 (plus recent CVE patches, i.e. as currently<br>
in Debian Stable) there is an issue with an integer underflow in the<br>
FILE mtime/ctime/atime check which basically seems to happen when<br>
finding the file to check takes a moment (seconds) and the file in<br>
question has been modified after the search for the file has been<br>
started.<br></blockquote><div><br></div><div>Is it possible that the time on the host being monitored is in the future, at least compared to the time of the Xymon server?</div><div><br></div><div>Can you provide the [clock] and [file:/nfs/...] sections of your client data message for an instance when the underflow has occurred?</div><div><br></div><div>It's hard to see how a delay in the collection of file timestamps could cause this underflow, as the creation of the [clock] section (the source of "now") is executed after the creation of the [file:] section (the source of the MTIME value). Essentially it's:</div><div><br></div><div>1. create tempfile</div><div>2. echo "client" header >> tempfile</div><div>3. run OS script >> tempfile</div><div>4. run "logfetch" to generate [file:] sections >> tempfile</div><div>5. echo client version section >> tempfile</div><div>6. run "logfetch --clock" to gelerate [clock] section >> tempfile</div><div>7. send tempfile to Xymon server</div><div><br></div><div>What you're describing is a situation where the time generated at step 4 is ahead of the time generated at step 6. I think this can only happen if the timestamp of the file is in the future.</div><div><br></div><div>However, If the [clock] section of the client message does not exist, the the Xymon server will use its own time for its calculations.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In such cases this integer underflow happens and causes a falso<br>
positive due to instead of the time difference being negative, it's<br>
insanely huge:<br></blockquote><div><br></div><div>No matter the cause, Xymon should take into account the possibility that the timestamp is in the future, and at least show "was modified N seconds into the future" or something similar, after handling or avoiding the underflow.</div><div><br></div><div>Perhaps create the following entry in clientlocal.cfg:</div><div><br></div><div>file:`exec >/tmp/clock-test 2>&1; date; $XYMONHOME/bin/logfetch --clock

; ls -l $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1; $XYMONHOME/bin/logfetch --clock; date`</div><br></div><div class="gmail_quote">The output file /tmp/clock-test might give you some idea of what's going on. Remember that it can take up to 10 minutes for updates to clientlocal.cfg to take effect on the client.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers</div><div class="gmail_quote">Jeremy</div><div class="gmail_quote"><br></div></div>