[syslog-ng] max recursion depth on filters?

[Balazs Scheidler]

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.

-- 
Bazsi