Date: Tue, 18 Oct 2022 08:49:54 -0400 From: Matteo Riondato <matteo@freebsd.org> To: Kristof Provost <kp@freebsd.org> Cc: Bryan Drewery <bdrewery@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: cfa1a1308709 - main - pfctl: fix recrusive printing of ethernet anchors Message-ID: <20221018124954.2vianlzyulewtldo@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu> In-Reply-To: <9B65580C-2959-4A01-8386-65E5AA596FC2@FreeBSD.org> References: <202209061119.286BJnOV024965@gitrepo.freebsd.org> <3fd7be3f-90b1-ae87-1b4e-8b183acf1a9c@FreeBSD.org> <46F2B94F-DBCB-4E55-8055-051393C900C8@FreeBSD.org> <55FAE484-FD9E-4652-AD1D-45FBF3501CE8@FreeBSD.org> <20221017173704.d3mvikbc25to6snn@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu> <9B65580C-2959-4A01-8386-65E5AA596FC2@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--pouxal6prtv2cfbn
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2022-10-18 at 04:44 EDT, Kristof Provost <kp@FreeBSD.org> wrote:
>On 17 Oct 2022, at 19:37, Matteo Riondato wrote:
>>On 2022-10-07 at 06:13 EDT, Kristof Provost <kp@FreeBSD.org> wrote:
>>>>On 3 Oct 2022, at 18:13, Bryan Drewery wrote:
>>>>>I think there's still a problem here.
>>>>>
>>>>>pfctl -a '*' -sr works pfctl -a 'name/*' -sr does not.
>>>>>
>>>So I=E2=80=99ve looked at this a bit more, and I am now going to back aw=
ay=20
>>>from the whole anchor thing, and try to pretend I didn=E2=80=99t see any=
of=20
>>>the tentacled horrors that lurk within.
>>>
>>>To give you an idea of the issues, loading the following ruleset:
>>>
>>> anchor "foo" {
>>> anchor "bar" {
>>> pass in
>>> }
>>> }
>>>
>>>does exactly what you=E2=80=99d expect:
>>>
>>> # pfctl -sr -a "*"
>>> anchor "foo" all {
>>> anchor "bar" all {
>>> pass in all flags S/SA keep state
>>> }
>>> }
>>> # pfctl -sr -a "foo/*"
>>> anchor "bar" all {
>>> pass in all flags S/SA keep state
>>> }
>>>
>>>However, if we `pfctl -Fr` to flush all rules:
>>>
>>> # pfctl -Fr
>>> rules cleared
>>> # pfctl -sr -a "*"
>>> # pfctl -sr -a "foo/*"
>>> anchor "bar" all {
>>> pass in all flags S/SA keep state
>>> }
>>>
>>
>>How is one supposed to know which rules are really loaded in this=20
>>case?
>>
>>Printing of rules with anchors being broken (I even get a segmentation=20
>>fault with 'pfctl -a "*" -sr -vv') makes debugging rulesets very hard.
>>
>`pfctl -a "*" -sr` should always produce the expected results, at least=20
>as far as I know.
The last example above clearly shows that `pfctl -a "*"` does *not*=20
always produce the expected results: after flushing the rules in the=20
root anchor with `pfctl -Fr`, `pfctl -sr -a '*'` does *not* produce the=20
expected results, which would have been
anchor "foo" all {
anchor "bar" all {
pass in all flags S/SA keep state
}
}
I'm wondering what gets printed if you load a ruleset such as:
block all
anchor "foo" all {
pass in all proto udp
anchor "bar" all {
pass in all proto tcp flags S/SA keep state
}
}
Then print it with `pfctl -sr -a '*'`, then do a `pfctl -Fr`, and then=20
do another `pfctl -sr -a '*'`, followed by a `pfctl -sr -a "foo/*"`. I=20
expect to see, again nothing for the `pfctl -sr -a '*'` after the flush,=20
and something like the following for the `pfctl -sr -a "foo/*"`:
anchor "foo" all {
pass in all proto udp
anchor "bar" all {
pass in all proto tcp flags S/SA keep state
}
}
which at least would (partially?) confirm that `pfctl -Fr` only flushes=20
rules in the root anchor.
>I=E2=80=99d be very interested in seeing a test case where that core dumps=
,=20
>because that is indeed very annoying, and might be something I can fix.
I'll try to come up with a minimally reproducible case (it is totally=20
reproducible with my settings, but I'd like to give you something=20
smaller).
>>Partially, the question I also have is: is printing of rules broken,=20
>>or is flushing of rules broken, or a third thing? =3D)
>>
>To the extent that I currently understand this problem I believe the=20
>issue is that we=E2=80=99re not always stepping into child anchors to prin=
t=20
>them. I believe they do get evaluated when the rules are processed. So=20
>it=E2=80=99s the printing that=E2=80=99s broken. The flushing is .. not br=
oken, but may=20
>not do what you=E2=80=99d expect. When we flush we only flush the root an=
chor,=20
>and other anchors can remain. I think that=E2=80=99s the main source of t=
he=20
>strange behaviour I=E2=80=99ve described.
Assuming that indeed `pfctl -Fr` really only acts on the root anchor,=20
what makes me worried is whether rules inside child anchors are really=20
evaluated *after* a flush of those in the root anchor with `pfctl -Fr`,=20
but checking if they really are evaluated should be an easy test.
Thanks,
Matteo
--pouxal6prtv2cfbn
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQJHBAABCgAxFiEEa9uKZL0hP4E8Nl5vGwL9SVQlVQEFAmNOoOkTGGhrcHM6Ly9w
Z3AubWl0LmVkdQAKCRAbAv1JVCVVAe/HD/9CdedQk86ef/YT7XL9yNxXZrkF8x03
bvIeSYa5PV5he3QVfMhOZB6xS9DOJ/Zcoh7P7oltx9G6SqbyspbREUoJKpXuEoDQ
75aroi6PQvpRMgngmoycT3Vi8J5mD7QMUJc3JdWQtQ9QIpUI9GQ0uY57g/Tzd2lH
dTkK58PMASiSJ5G42kVB3MaS2mewjzbKcauBEf4g0lxk0/bUpBDf5kmx5mI9E1yP
5N0WJdNRK/1PifOWBBX/JlCpYE9O8DZ6TBFeVXlDR6VDN6UekQm2ONKYT0U/eCOU
vCsIzUm3YpWMFAvCjCiI6K+dbM1eS4kXc4c83rkQLhHLkW2AGuYXDc1ih0jcGJfV
9WQITpkSvRTendFOqEflL6Lhe82BO+F7trrlapg4TxNSnHSXJW+xa04l9dDHbFVT
OS8wRBWZZqa3hWLdoOqsnLrZRSYHZeX1GZ5IzXDeYOmzi8s7qj0jB3nmSV6m1hvF
i4bXOeIhkwPnhEH3Q0czdvQaG+eboTgrBGyfAm06nyhevXDaQRZh3TSysqeaJbIk
+8tzR7uFUccBXUkJL335mdf3Rru1osWjoz0jUwKmdweD7uu2H599rffp6UmJv1cO
NHizDBV8pGmQVe1ixoNwSirP+RCmvhNcYpklrJ2/V0ACVzpWMcejmzRMVgGzWSJL
SqChqK9OZBExpw==
=WP7a
-----END PGP SIGNATURE-----
--pouxal6prtv2cfbn--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20221018124954.2vianlzyulewtldo>