[Bug 262622] [pf][patch] fix showing rules in (some) nested anchors
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 262622] [pf][patch] fix showing rules in (some) nested anchors"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 17 Mar 2022 17:39:43 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262622 --- Comment #7 from Matteo Riondato <matteo@FreeBSD.org> --- (In reply to Kristof Provost from comment #6) This fixes the issue I outline here (but my patch already did that, and it is simpler: I don't think copying anchor_name is needed, as least for this specific issue). The issue in bug #262590 is a little subtler: 1) we don't recursively print rules in anchors included in pf.conf with a wildcard, for example, using "anchor blacklistd/*". Here is the output from "pfctl -a "*" -sr" with a pfctl patched with your patch: anchor "*" in on lagg0 all { pfctl: DIOCGETRULES: Invalid argument } Note that that "*" is wrong, it should be "blacklistd", but the assignment of p around line 1250 of pfctl.c is too naive, as it should take into account the current values of path and of anchor_call before deciding what path/anchorname to use next (indeed the error is due to pfctl_get_rules_info being called with a path of "*") 2) we don't recursively print rules in other cases, but it is a little weird when it happens, as it only happens in some cases. For example (with pfctl patched with you patch): On one hand: # /usr/obj/usr/src/amd64.amd64/sbin/pfctl/pfctl -a "blacklistd/*" -sr # (no output) but there is a nested anchor "2200" under "blacklistd", and its rules should be printed by the above command. Indeed, if we try to print its rules directly it works: # /usr/obj/usr/src/amd64.amd64/sbin/pfctl/pfctl -a "blacklistd/2200" -sr block drop in quick proto tcp from <port2200> to any port = 2200 # Although, it is really weird, because the following works: # /usr/obj/usr/src/amd64.amd64/sbin/pfctl/pfctl -a "test/*" -sr anchor "test2" all { block drop in proto udp from any to any port = 3999 } # In any case, the situation there is more complex than what is addressed with this patch, which is still needed independently. -- You are receiving this mail because: You are the assignee for the bug.