John P. Rouillard wrote: > In message <[EMAIL PROTECTED]>, > Risto Vaarandi writes: >> does anyone have comments on the new release? >> Since it's the first beta, things are still open now and changes can be >> made. > > I am finally reading the man page. So that's progress right?
:-) First of all -- thanks for the remarks. I'll provide my comments and explanations below. > > One thing I can see being useful is to allow $1 variables to be > replaced in the cfset. E.G. > > type=jump > pattern= (sshd|dhcpd|heartbeat): > cfset = $1-rules > > So in one rule/pattern (which is executed much faster than the three > equivalent rules with their own patterns) I can select any one of > three rulesets very quickly. I can see your point. I went deliberately for constant set names, because then no substitutions have to be made anywhere in the rule definition. The substitution process is unfortunately quite expensive operation -- it involves creating a copy of relevant data structures from the rule definition, and then scanning these for $-variables. One might think that this process could be avoided with the Perl (?: ) construct -- but unfortunately, the $0 variable will *always* be set, whether there were any parentheses in the regexp or not, and this will automatically trigger the substitution process. (BTW, this is the reason why SubStr does not support $0 -- this pattern type is supposed to be as lightweight as possible, without any burdens at all.) After having explained the current design and also realized your point, I need to think about possible solutions. One one hand, I'd like to retain an opportunity for really fast regexp matching without additional work, because Jump-rules are usually applied for all input data and they have to be fast. On the other hand, using variables in set names is handy from time to time. Therefore, in addition to 'cfset' I could introduce another field (perhaps 'cfset2') that would support the use of variables at the expense of matching efficiency. > > Also what happens if the cfset doesn't exist? Does it act as though > cfset wasn't specified (and therefore is an equivalent to a suppress)? > If so does it also report an error? If a set in 'cfset' does not exist, an error is logged; also, you will get an error when a loop is detected (Jump directs the matching to a set A that the matching process has already seen during previous jumps for the same input buffer content). If the 'cfset' field is missing altogether from the rule definition, the further processing of the current input buffer content is determined entirely by the 'continue' field of the Jump rule (if set to DontCont, Jump behaves like Suppress; if set to 'GoTo', Jump behaves like a fast Goto operation). > > Also I would suggest renaming the type "Options" and naming it Access, > AssignSet or something instead. Options to me sounds too much like > something you want to use to set the command line options for > SEC. It's just too generic kind of. Need to think about it a bit... maybe there will be another options available in the future? > > Also the 'inputsrc' value doesn't really seem to describe what it's > doing. Maybe: > > accessibleFrom = jump > accessibleFrom = all > > eeeh not loving that earier, but hopefully you see what I mean. Maybe > > onlyjump = yes (for inputsrc = jump) > > onlyjump = no (for inputsrc = all) > Well... I had a lot of doubts about that name, but couldn't find any better option. For a while I was thinking about matchall=(yes|no) (i.e., define if the current ruleset is used for matching all input or not). > The inputsrc is not checking the input source at all (compare to the > contexts associated with input files that really does limit things by > input source). It's setting how that rule set is accessed. > > Also is it possible to take an: > > type = option > joincfset = default-rules > inputsrc = all > > and perform a > > type = jump > ptype = tvalue > cfset = default-rules > > So I can get: > > A jump C jump default-rules (aka D) -> E > > A -> B -> D (aka default-rules) -> E > > where the last is the default processing order based on the order of > the rules files. > > Also is it true that I can get: > > A jump C jump default-rules (aka D) -> E > > or does the first jump to C and then to D stop D from continuing to > the E rules file? I am not entirely sure I've got the question... did you mean to ask if the matching process moves to E, once the 'default-rules' set has been processed (because E comes after D)? The answer is no -- once the set has been processed, the matching process continues from the point where the jump was made from. > > Also one other thing that may be useful is to assign every > configuration file to it's own unique cfset using the basename of the > file. So if I had the rules files: > > A.sr, B.sr, C.sr > > I can always (regardless of the existance of any option statements): > > type = jump > pattern = a > cfset = C.sr A.sr > > type= jump > pattern = b > cfset = B.sr A.sr > > if I need/want to explicitly order them. I could define the option as > well I guess, but it would be a nice convenience to be able to use the > file names themselves as though: > > type=options > joincfset = A.sr > inputsrc = all > > was specified in A.sr, similarly in B.sr, C.sr. I see... the set names have one important advantage, though -- they are written down explicitly and if file names change, the jumping mechanism does not break. Also, currently a membership in a set means the rule file is not applied for matching all input by default. Having default names around which don't involve the same effect might make things harder to follow sometimes... (The current mechanism in 2.5.beta1 is quite similar to the approach taken by iptables -- only these rules that are present in the builtin (main) chain are used for matching all packets; once you create a custom chain, it must have an explicit name and it can match packets only if you direct them to that chain.) WBR, risto > > Well guess that's enough drivel from me for now. > > -- > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less my opinions. > > ------------------------------------------------------------------------------ > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > _______________________________________________ > Simple-evcorr-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
