Closed opty77 closed 1 year ago
Unable to reproduce on 32-bit Slackware 15.0 using debugging instance.
Reproduced on 64-bit Slackware 15.0 using /usr/sbin/syslogd -dssF -f $CONF -p $SOCK -C $CACHE -P $PID -cc |& tee -a $OUT &
and echo subseconds >> /dev/kmsg
(for the completeness):
2023-06-20T18:06:00.431123+02:00 qeporkak syslogd 3462 - - syslogd v2.5.0: restart.
2023-06-20T18:10:00.000000+02:00 qeporkak kernel - - - subseconds
2023-06-20T18:12:40.721761+02:00 qeporkak syslogd 3462 - - exiting on signal 15
So either it depends on the bitness or this particular machine.
Reproduced on 64-bit Debian GNU/Linux 11.7 (Bullseye) in an LXC container.
-t
works there, just for sure.
sysklogd-2_5_0-ustime-untrusted-syslogd_c.diff
:
--- sysklogd-2.5.0/src/syslogd.c 2023-04-30 20:08:56.000000000 +0200
+++ sysklogd-2.5.0+uu/src/syslogd.c 2023-06-27 13:18:01.808434676 +0200
@@ -1404,7 +1404,9 @@
tv.tv_sec = time(NULL);
tv.tv_usec = 0;
}
- ustime = tv.tv_usec * 1000000;
+ /* Useless? */
+ /* ustime = tv.tv_sec * 1000000 + tv.tv_usec; */
+ ustime = tv.tv_usec;
}
localtime_r(&now, &buffer.timestamp.tm);
Seems to work.
Yeah, you're right, this should do the trick. Thank you for tracking it down!
- ustime = tv.tv_usec * 1000000;
+ ustime = tv.tv_usec;
There, merged to master. Will be in the v2.5.0 release, which I honestly have no timeline for yet, but should be out at the end of the summer (when I have vacation :)
2.5.1?
Ouch, yeah you're right. I meant v2.5.1 ... too many projects queued up so I'm mixing them up.
https://github.com/troglobit/sysklogd/commit/1e9f164198c527f123ede182883d3e6c29b27e2c should have brought untrusted kernel messages timestamp sub-second faking but it doesn't seem so: