In message <[EMAIL PROTECTED]>,
Risto Vaarandi writes:
>I have given it some thought and there are some at least some ways of
>doing this. There could be a special command line flag (e.g., -conf2)
>which loads a rule file, but doesn't use it for matching input lines by
>default. Instead, a user could employ the 'jump' action to tell SEC to
>use specific rule file only.
That's probably the way I would go initially. Along with
jump file [rulename or number]
similar to how reset addresses individual rules. By default it would
start at the first rule in the file. Alternatively a new rule type:
type = label
decription = a label to branch to.
would identify the location to jump to in a file. It could also jump
into the current file at a given label as well to skip a series of
rules that can't possibly match.
You also need a "jump return" action to return to the calling rule
sequence, similar to executing the RETURN target in iptables.
Now the question is does the jumped ruleset occur in virtual parallel
(like multiple config files currently do) or in series with the
"caller" rules file?
I don't have a real opinion on which is better.
Also one other thing to look out for is jumping in a loop.
so a rule in file a calls
jump b
and a rule in b calls
jump a
I think currently you can't get into a loop. Processing of every input
line will eventually exit. In one of my other posts on branching/flow
control I think I mentioned a mechanism to prevent loops by forcing
the call sequence to be a tree. But I am not sure if that is too
strict.
>Another way to enable branching would be to
>have 'load' and 'drop' actions for loading configuration from additional
>rule files at run time, and then let user to employ 'jump' for narrowing
>the matching process to given files only.
I can see this being useful to load dynamic rules, but I think it's
less useful than statically specifying the files and using USR1 to do
the load/reload.
>Instead of files, I've been
>thinking of using textual tags, e.g., 'load linux
>/etc/sec/linux/*.rules', 'jump linux', etc. (or
>-conf2=/etc/sec/linux/*.rules=linux which is somewhat similar to
>specifying input file contexts for SEC).
I would kind of like the rules file to know that is is a callable
module. Maybe a new rule type:
type = callable
description = myrules
where the (optional) description is used as the "textual tag" for the
jump command. If they wanted a more descriptive name than a filename
would allow they can use the description field. This would occur as
the first rule in the branch/callable file (and could identify the
file as a callable file). If the description was missing, use the file
name (the part with directory names stripped off).
I could live with the conf2= model as well as I could just use .csr
(callable sec rules) as an extension to differentiate from the .sr
(sec rules) files.
P.S. any SEC users going to be at LISA in San Deigo next week?
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Simple-evcorr-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
