RFC5424 and all transports (except obsolete non-octet-counted TCP) can handle MSG containing ANY character including newlines and carriage returns.

In violation of the above, NxLog's to_syslog_ietf() function backslash-escapes these two characters. Furthermore, the escaping scheme is broken because it doesn't also escape the escape character itself (the backslash) so there's no way to reliably un-escape the MSG on the receiving end.

The correct behaviour is to stop escaping these characters altogether. In the rare case that someone needs to send multiline messages over non-octet-counted TCP, they can escape/unescape the $Message themselves using NxLog's replace() function.

Patch below.

RFC References:

Ron MacNeil

--- src/modules/extension/syslog/syslog.c.orig 2014-07-19 23:52:06.000000000 +1000
+++ src/modules/extension/syslog/syslog.c 2016-07-26 14:01:57.296175500 +1000
@@ -1321,16 +1321,8 @@

// Append message
- i = (int) logdata->raw_event->len;
nx_string_append(logdata->raw_event, " ", 1);
nx_string_append(logdata->raw_event, msg.string->buf, (int) msg.string->len);
- for ( ; i < (int) logdata->raw_event->len; i++ )
- { // replace linebreaks with space
- if ( (logdata->raw_event->buf[i] == '\n') || (logdata->raw_event->buf[i] == '\r') )
- {
- logdata->raw_event->buf[i] = ' ';
- }
- }

if (tmpmsg != NULL)
{ // clean up temp copy

AskedJuly 26, 2016 - 6:26am

Answer (1)

The code you removed with the patch does what it says in the comment (// replace linebreaks with space) and there is no escaping done there.

Note that this has been added because linebreaks cause issues with TCP/TLS transport when octet framing is not used.  I know this too can be done with the replace() function but it seemed better to do this explicitly. Perhaps a RemoveLinebreaks configuration option could be added to xm_syslog to satisfy everyone.


Comments (1)

  • ron-macneil-ice's picture

    Yes, please disregard that brainfart of a patch.

    My reading of RFC5425 -- https://tools.ietf.org/html/rfc5425#section-4.3.1 -- tells me that there is no such thing as unframed TLS, leaving unframed TCP as the only transport of the four that can't handle linebreaks.

    The other transports -- UDP, TLS, and framed TCP -- can all handle linebreaks. So I think there is a good case for your proposed RemoveLinebreaks option. We would certainly use it at our site, where we do want linebreaks in our log messages and our entire logging pipeline (with the exception of NXLog) can handle them.

    Thanks for the great tool.