On Tue, Sep 15, 2020 at 12:30:35AM +0200, Klemens Nanni wrote:
> Actually, that should just work regardless of whether the rounting
> domain exists at ruleset creation time; just like it is the case with
> interface names/groups which may come and go at runtime without
> requiring changes to the ruleset.
>
> Rules on nonexistent interfaces won't match, routing domains (and
> ultimately routing tables) should behave the same, I think.
>
> Here's a diff that does this for routing domains allowing me to always
> use `on rdomain 5' - I've tested it with a few examplatory rulesets and
> behaviour is as expected.
>
> It will need more eye balling and I am not pushing such changes before
> release, but if that is a general direction we agree, your proposed
> `rtable' fix could move along and become just as flexible instead.
More on this:
# ifconfig lo1 rdomain 1
# echo pass on rdomain 1 | pfctl -f-
# ifconfig lo1 destroy
# pfctl -sr
pass on rdomain 1 all flags S/SA
The ruleset stays valid and continues to work as soon as routing domain
`1' reappears, there is no reason to require existence of it at ruleset
creation; this is safe because routing domains are just normative
numbers, there's no further state when it comes to filtering - either
the id on the packet matches the number in the ruleset or it doesn't.
Routing tables however are more involved as they can be used to *alter*
a packet's flow in pf.conf(5), so requiring them to be present at
ruleset creation makes sense to guarantee that pf will only ever change
routing table ids to valid ones.
Routing domains can be deleted, but that doesn't invalidate rules like
`on rdomain 1', which simply won't match when the given id does not
exist.
Routing tables however cannot be deleted, they get moved to the default
routing domain whenever their corresponding routing domain disappears;
this is in line with only ever loading valid routing table ids into pf.
So unless I missed something, that ruleset creation (`pfctl -f ...')
is the only occasion pf actually needs to validate routing table ids:
they are guaranteed to always exist from then on.
Given this, my diff looks fine as is and should not change `rtable'
behaviour - YASUOKA's diff is also fine as is and actually implements
the validity check I just mentioned, obsoleting my initial feedback.
