> -----Original Message----- > From: [email protected] [mailto:rsyslog- > [email protected]] On Behalf Of [email protected] > Sent: Wednesday, October 28, 2009 3:57 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog and snare > > On Wed, 28 Oct 2009, Rainer Gerhards wrote: > > >>> Jan 1 01:01:01 > >>> mail.abc.com#011MSWinEventLog#0111#011Security#0114169#011Fri > >>> > >>> while in syslog format it does > >>> > >>> Jan 1 01:01:01 mail.abc.com > MSWinEventLog#011Security#0114169#011Fri > >>> > >>> > > > > First things first: I really don't like to dig into snare, as I do > not think > > it is a really good solution (but how could the designer of > > http://www.eventreporter.com say otherwise? ;)). > > > > so I assume you are talking about this message: > > > > mail.abc.com#011MSWinEventLog#0111#011Security#0114169#011Fri > > > >> Basically rsyslogd should respect RFC 3164 (Any non-alphanumeric > >> character > >> will terminate the TAG field and will be assumed to be the starting > >> character of the CONTENT field.) > > > > Another thing to put straight: RFC3164 is NOT a standard, it is an > > informational document that describes things seen on the wire. And it > does > > not even describe all *popular* cases. If it all, it gains some > standard > > function via RFC3195, but this is questionable. Just for the records > ;) > > > > So the key point here is that we have nothing to "respect" or "obey > to", but > > rather something that describes things seen in practice. For any > decent > > syslog receiver, this means it must try to work equally well with > everything > > that comes in via legacy syslog. But, granted, RFC3164 is useful if > we have > > nothing else to look at. > > > > So let's do that. We'll immediately see that snare is broken, because > no > > control characters are allowed in the hostname. So rsyslog does the > right > > thing and escapes these characters. So everthing belongs to the > hostname and > > thus you have problems with tag. > > two other valid behaviors > > 1. it has a control character in the first text field, so that cannot > be a > hostname or a tag, so it must be part of the message (after doing the > escaping) > > 2. treat running into a tab like running into a space > > I think #1 would be better than what we do today, but #2 would be the > best > for users.
The problem with all that is that it breaks message sanitation. When a message hits rsyslog, it first is sanitized (which is important for security reasons, e.g. to prevent NUL characters to make parts of the messages unreadable and, later, to prevent the myriad of Unicode-based Vulnerabilites). So when it hits the parser, the is no such thing like a HT present anymore. What we could do, however, is add an option that tells the sanitizer to replace HT by SP in all cases. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
