> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] 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 > control > > > 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 > forbid > > 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 [1] and I convert any control characters to > spaces > 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 sequence). I am sorry if the context was not 100% clear, I had thought the blog post provided everything (and I was obviously wrong...). Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
