[Xymon] Integer overflow in client-side files check
Axel Beckert
abe at deuxchevaux.org
Fri May 3 21:13:12 CEST 2019
Hi,
occassionally determining which file to check takes so long that the
file has been modified already after the "files" check started but
before the file timestamp is actually checked. Hence the file might
have a negative age.
But since the variable where this is stored seems to be unsigned,
this causes false positives due to an integer overflow:
> red /nf/2019/05/03/201905032050
> File was modified 4294967291 seconds ago - should be <360
> File was modified 4294967291 seconds ago - should be <960
This probably only happens if the file to check first has to be found
using backticks or $(...) -- which may take some time.
In our case the according line in client-local.cfg looks like this:
file:`ls -1 $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1`
Timing examples:
> $ time ls -1 $(ls -1d /nf/2???/??/??/ | tail -1)* | tail -1
> /nf/2019/05/03/201905032055
>
> real 0m0.015s
> user 0m0.003s
> sys 0m0.004s
I see several potential solutions in decreasing preference:
A) Don't compare to the check startup time but always to the time at
which the file timestamp is checked.
B) Use a signed integer instead of an unsigned integer.
C) Ignore timestamps newer than "now" when comparing with "<".
Actually IMHO the proper fix would be to implement both, A and B.
P.S.: Happens with 4.3.28 installed from Debian Stretch's xymon
package. Haven't checked with the 4.3.29 branch, but there was nothing
related listed in 4.3.29's Changes file so far.
Kind regards, Axel
--
PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet
Mail+Jabber: abe at noone.org X
https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
More information about the Xymon
mailing list