On Wed, 5 Nov 2008, John P. Rouillard wrote: > In message <[EMAIL PROTECTED]>, > Risto Vaarandi writes: > >> John P. Rouillard wrote: >>> In message <[EMAIL PROTECTED]>, >>> Risto Vaarandi writes: > >>> 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 was thinking of virtual parallelism... this, of course, makes the >> possible 'return' action semantics a bit more blurry, since in principle >> the rule file processing order depends on the character order on your >> system [...]. > > Why? Return returns up the call stack. No ambiguity AFAICT. It gotbes > to the rule with the jump action and continues processing from > there. Now there may be a problem for actions after the jump. > E.G. > > action = jump a set_context_1; report context_1 "mail" > > in this case, I would expect the report to use the contents of > context_1 as set by the rules executed by the jump. However there > maybe some things (like command line context/variable substutions) > that are done when the action is evaluated and not when the > inidividual action is executed. E.G. > > action = jump a set_variable_f; report context_1 "%f" > > What value is substituted for %f? The value before the jump, or the > value after the jump? I think it's the former but I could be wrong. >
this follows the pattern of iptables/ipchains firewall rules, you can do a match and then say 'go to this other list of rules'. that list of rules can do whatever other matching it wants to, and by default when it is done you continue back after the jump. If you choose to have a rule in that other list be definitive (which for SEC is the 'don't process this line anymore'), it has nothing more to do and goes to the next line. it doesn't matter if the rules are inline in the main config file, or if they are part of a chain getting jumped to. If you make a mistake and set a rule to jump to itself you have a problem, but then you can have a problem with a rule generating a log entry that that same rule matches (generating another log entry....) if it's easy to detect such things, do so. but if it's hard, document this as a "don't do that" and leave it at that (possibly have a static checker that looks for potential loops and warns about them at startup, but don't waste processor at runtime trying to detect them) David Lang ------------------------------------------------------------------------- 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
