[syslog-ng] 3.7.1 patterndb matching rule preference fix - incorrect

[Evan Rempel]

The release notes for Syslog-ng 3.7.1 include a bug fix to the patternDB as shown below.

PatternDB

     Earlier, in patterndb, the first applicable rule won, even if it was only a partial match. This means that when rules overlapped, the shorter match would have been found, if it was the first to be loaded. A strong preference introduced for rules that match the input string completely. The load order is still applicable though, it is possible to create two distinct rules that would match the same input, in those cases the first one to be loaded wins.
-------------


I think that the choice of using the longest match does not reflect the intention of the person making the pattern. Consider these two messages and patterns

1.
MESSAGE: Failed to open /var/local/tmp/mailguard/mailguard_timestamp for writing: OS error 5
PATTERN: Failed to open @STRING:workingfile:/_@ for writing:

2.
MESSAGE: Failed to open /var/local/tmp/mailguard/mailguard_timestamp
PATTERN: Failed to open @ANYSTRING:workingfile@



The first pattern does not match the entire line because it already identifies that it was an error for writing.
The second pattern matches the entire line, but the intent was just to match fie file name. ESTRING can not
be used to limit the amount of text matched in the #1 message because there is no trailing space on
the #2 message.

What I am leading up to is the discussion that the first pattern is more DEFINITIVE because it has more
STATIC content in the PATTERN. It does not matter that the second pattern matched more of the message.

When a human writes a pattern, they try to make the pattern as specific as possible. They do that by including
as much STATIC content in the pattern. The more variable content that a pattern matches implies that the pattern is
more of a "catch all" than patterns with less variable content.

To make the current implimentation of PatternDB work, EVERY pattern must match the ENTIRE message. This means that many
patterns will have a @ANYSTRING@ needed at the end of them.


I propose that the PatternDB preference be changed from the pattern with the longest MATCH to the pattern with the largest amount of static content.


Discussion/comments?

-- 
Evan Rempel