--On Thursday, April 16, 2009 03:08:49 PM +0100 Stuart Henderson
<[email protected]> wrote:
pf.conf(5) is reasonably clear about this, I think...
"ANCHORS
Besides the main ruleset, pfctl(8) can load rulesets into anchor
attach- ment points. An anchor is a container that can hold rules,
address ta- bles, and other anchors."
...
"Anchors may end with the asterisk (`*') character, which signifies
that all anchors attached at that point should be evaluated in the
alphabeti- cal ordering of their anchor name. For example,
anchor "spam/*"
will evaluate each rule in each anchor attached to the spam anchor."
did you find this confusing, and if so, can you suggest any changes we
could make that might help make it more clear?
Yes, I found it confusing, and I still do.
So, is the answer to my question this?:
If you say anchor "spam" (to use the example above) then all rules
"immediately" contained in the anchor spam are evaluated, but rules in
sub-anchors within spam are not.
If this is the right idea, then it would be helpful to say this explicitly
in the FAQ.
Of course, as I understand it, if you say anchor "spam/*" then a rule in
anchor spam/foo will be evaluated, but a rule in anchor spam/foo/bar won't
be.
This all seems very strange. What goes wrong if you leave off "/*" is that
sub-anchors don't work? But if you do put "/*", then sub-anchors *STILL*
don't work if they're nested more than one level deep?
So, if you leave off "/*" you're assuming your anchor has no sub-anchors --
but if you put "/*" then you are assuming there are no sub-sub-anchors ...
What happens if you say
anchor "spam/*/*"
?? Will this pick up everything "immediately" contained in anchor spam as
well as everything down to two levels?
From the FAQ:
The child anchors will be evaluated in alphabetical order but are not
descended into recursively
Sigh. I'm having difficulty understanding why you wouldn't *want* recursive
descent just by saying anchor "foo".
