[rsyslog] Feedback Request: NULs in strings?
rgerhards at hq.adiscon.com
Wed Nov 3 17:57:48 CET 2010
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of Sean Conner
> Sent: Wednesday, November 03, 2010 5:50 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] Feedback Request: NULs in strings?
> It was thus said that the Great Rainer Gerhards once stated:
> > > No, I meant the semantic meaning of NUL is syslog messages. Why
> > > would you
> > > want to log a message with such a character? (or any of the
> > > characters really)
> > I really don't want it, but an attacker may induce it. The need, as
> far as
> > the discussion goes, stems back to the fact that we cannot reliably
> > its use. But you are right at the heart of the discussion:
> > Should we try to forbid it (knowing that we can't 100% ensure that)
> or should
> > we somehow handle it.
> I checked my syslogd  and I convert any control characters to
> upon receipt of a message. The actual code I have:
That's nice to know, but it unfortunately is not an answer to the question I
asked. That question was not how a syslogd should handle NULs, but how a
library should handle NULs that a library user (app) potentially pushes to
it. My question was how to deal with that, and most importantly: is adoption
more important than technical soundness?
This is within the context of log normalization and the CEE effort. For
syslog and rsyslog, the answer is already clear, you can find it in RFC5424
(NULs permitted, but receiver is permitted to change them to a different
I am sorry if the context was not 100% clear, I had thought the blog post
provided everything (and I was obviously wrong...).
More information about the rsyslog