From nobody Tue Oct 18 12:49:54 2022 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MsDGb2ZSHz4fTVv; Tue, 18 Oct 2022 12:49:59 +0000 (UTC) (envelope-from matteo@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MsDGb1h7wz461d; Tue, 18 Oct 2022 12:49:59 +0000 (UTC) (envelope-from matteo@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666097399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5wVQKgOQy/ikAdHB7OaUAvhVRamFBMHOErSiIQs4Gt4=; b=XmKnmy9gDuGPvUh/y6ccNq9aUgt8uElra5E9L3Uo5XoALuP7tEUbHpzgCOKZ/KhR5lYsW9 dfZu9C+MVlTfVEp1UCUKvOq4/dsr7GW30ZukB7q5J0qcU7cd19krC3z9ENWhB6Czsdjm+k eaT+S9QfpIeCpe1EC1QM1pXiRcrf1XTiLwhxjXQVHcAq/XD4nXVlEoR7D3hs09gZxOeVrF /bxS0uHVPnYQa1mngBpR4cmYGf6Ty4RPSCfHtYwGUfO/yekj8ZPqLso7ptgDdTDzEteAD3 zC57Mwt0TfJ1rQP2qo/UZ64H8Q8RGlE94IFGcGQOi18baH6bjLs76NcTYcXieg== Received: from host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu (pafw-natd-255-146.amherst.edu [148.85.255.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: matteo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MsDGZ6vpvz1YSL; Tue, 18 Oct 2022 12:49:58 +0000 (UTC) (envelope-from matteo@freebsd.org) Date: Tue, 18 Oct 2022 08:49:54 -0400 From: Matteo Riondato To: Kristof Provost Cc: Bryan Drewery , 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> X-PGP-Key: http://rionda.to/files/matteogpg.asc 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> List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pouxal6prtv2cfbn" Content-Disposition: inline In-Reply-To: <9B65580C-2959-4A01-8386-65E5AA596FC2@FreeBSD.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666097399; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=5wVQKgOQy/ikAdHB7OaUAvhVRamFBMHOErSiIQs4Gt4=; b=cFESi9VtznTAyGKas6Yn3iP+D0+zTmtVClDqOeUgGWn9L70MkI3CUCF8A/5B9QYZBfjn9n 5b+Kxz4/ccaapwLmh0KTlVbOcxr79BrfW6LDHPNYlF+nD+YTh5GFrigISY3NbtABIfWtAs G03PU181LaNExxvuANAGrUqviNl9jRwdM4inE0z4Om5Xt2Vt6Id8jdkcxxQlNsfO4Ypr7+ K1AYFnEScCrAWUY8WQxVZtPEnuDlyRDL0/c4K19sjyEdhpLSj7Q0X6hLaW5pNb76zjiKEW a83NENpxU5OiOIHFqD2MYKubHUBlCES323jWktbk+OPdVgj9qFy5T1+wmTaasw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666097399; a=rsa-sha256; cv=none; b=qeNolMI4CTsnw6T7jkMc609y5h98xssQX33kZn+QaHCtxJHpUNr8cOZDIM25/BlOKBpeW0 C4VDbIFSP3M7LiXvkBrIfg74zL9qiV0gr+xPDQTFiH9Uhz1VVPblFBRAIqpu0EMqzf8+eM +qRqO6Xp/8fxDNY8mUtX8pBUayAYT/45W9Nzx+fItaMHVE2SOQcJpAXDF9E2q6K7CEGp9f tepG6b4yjSB7GogmV/bkvzuFyKD29t8mLnrvIH7dcedOL/7HLvyiHUF6+V1M6FRUo5wMBy 29ISxhoQWgWULsgA/MKlHSUmQXrWzvOXLzPU1E55c547uIVjBwivg/zeF5/AGA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --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 wrote: >On 17 Oct 2022, at 19:37, Matteo Riondato wrote: >>On 2022-10-07 at 06:13 EDT, Kristof Provost 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--