[syslog-ng] max recursion depth on filters?

[Patrick Hemmer]

Sent: Sun Mar 11 2012 07:26:20 GMT-0600 (EDT)
From: Balazs Scheidler <bazsi at balabit.hu>
To: Syslog-ng users' and developers' mailing list 
<syslog-ng at lists.balabit.hu>
Subject: Re: [syslog-ng] max recursion depth on filters?
> On Fri, 2012-02-03 at 20:37 -0500, Patrick Hemmer wrote:
>> Is there a maximum depth on recursive filter statements?
>> I seem to have an issue which would indicate so.
>>
>> For example, in the config below, i have f_discard, which calls
>> f_iptables_discard, which calls f_iptables. I have it like this so
>> that its easy to read, configure, and add other filters. Its supposed
>> to result in lines matching this to not be logged, but its not
>> working. However if I take the contents of `f_iptables_discard` and
>> put them directly into `f_discard` it works fine.
>>
>> filter f_iptables {
>>      program('^kernel')
>>      and message('^\s*\[\s*[\d\.]+\] iptables/' type(pcre))
>> };
>> filter f_iptables_discard {
>>      # ignore iptables broadcast messages
>>      filter(f_iptables)
>>      and message('MAC=ff:ff:ff:ff:ff:ff')
>>      ;
>> };
>>
>> filter f_discard {
>>      not (
>>          filter(f_iptables_discard)
>>      );
>> };
>> rewrite r_tag {
>>      set('iptables', value('DBTAG') condition(filter(f_iptables)));
>> };
>>
>> log {
>>      source(s_local); source(s_net);
>>      rewrite(r_tag);
>>      filter(f_discard);
>>      destination(d_sqlite);
>> };
> Nothing intentional, however there was a bug in filter() expression
> evaluation, namely it wasn't resolving the nested filter properly in
> case it was embedded as a part of an "AND" or "OR" subexpression.
>
> This patch was fixing it:
> Author: Balazs Scheidler<bazsi at balabit.hu>   2011-10-23 20:19:58
> Committer: Balazs Scheidler<bazsi at balabit.hu>   2011-10-23 20:19:58
> Parent: 46bbdf9a107409e320450f9c4b6a82c2cf9f36af (LogMatcher: fixed reference counting)
> Child:  a2b4febbd1a6147762420a227600afba0eff4778 (configure: don't use non-standard arguments for "head")
> Branches: many (30)
> Follows: v3.3.1
> Precedes: dfsg/3.3.2_0, v3.3.2
>
>      filters: fixed filter() evaluation when embedded as an AND/OR subexpression
>
>      When introducing the "init" method for filters one case was omitted: even
>      though AND and OR expressions don't want to do anything on init, their
>      subexpressions might, so this patch adds an init function to AND and OR
>      which does nothing but calls the same for its "left" and "right"
>      subexpression.
>
>      This patch fixes filter("xxx") expression evaluation when that is
>      not a single expression, but rather included in an AND or OR.
>
>      Reported-By: Leonid Isaev<lisaev at umail.iu.edu>
>      Cc:<syslog-ng-stable at balabit.hu>
>      Signed-off-by: Balazs Scheidler<bazsi at balabit.hu>
>
>
> This was released as a part of 3.3.2, so you shouldn't be affected.
I'm experiencing the issue on 3.3.4 :-(

-Patrick