On Wed, Jan 02, 2019 at 11:27:18PM +0100, Alexandr Nedvedicky wrote:
> I don't object your change. However I hesitate to give OK too. I hope PF
> users, who have non-trivial rulesets will speak up here.
Feedback is welcome.
> IMO opinion we are hitting limitations of pfctl(8) here. Making warnings
> more useful requires to introduce some additional hints to pfctl, to
> better express, which table should be bound to rule.
This does not seem like a limitation to me.
> Currently pfctl(8) tries to use table, which is attached to anchor.
> If there is no table found, it implicitly fall backs to main anchor
> and uses table found in main anchor (ruleset). This implicit fallback
> is source of our doubts:
> is it intentional the table at anchor is not defined?
Pretty sure that's by design. All tables used to be global, until
cedric reworked lookups at 30.04.2003 to be hierarchically per anchor.
> I would prefer pfctl(8) to always complain if particular table is not defined
> in anchor. e.g. if rule refers particular table as:
>
> pass in from <t1> ....
>
> then parser should always expect `t1` to be defined in the same anchor
> as the rule itself. If no table is found anchor, then parser should
> exit with error.
Yes, but referring/accepting non-existing tables is a different issue.
Now I want to (naively) take care of better collision warnings only.
> If user wants rule above to use `t1` from main
> anchor then the rule should look like:
>
> pass in from </t1> ....
>
> I agree going that way just puts more pain to users for kind of
> little gain.
What *is* the gain? I don't see it.
> > # ./obj/pfctl -T replace -t t3 -a a2 -n
> > pfctl: warning: table <t3> already defined in anchor "/"
> > pfctl: warning: table <t3> already defined in anchor "a1"
> > 1 table created (dummy).
> >
>
> I just see an use case above from different perspective:
>
> it's not a problem where particular table is defined,
> the tricky question is how do we refer them in rules.
Just by name as it's done now, leaving scope to anchors alone.
How would the user interface look like?
pfctl -a foo -t /t
pfctl -a / -t /t
pfctl -t t
pfctl a foo -t ../bar/t
pfctl -t bar/t
How should these behave? Thinking about hierarchies in two places makes
for a big mess.
> As I've said I don't object your change. I agree it does,
> what you intend, however I'm not sure how much it buys.
My intention is to make warnings clear and unambiguous, such that
referred table and anchor names can be copied and pasted into successive
pfctl invocations to fix things right away.
