From nobody Tue Oct 18 08:44:32 2022 X-Original-To: dev-commits-src-main@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 4Ms6qR2vdjz4gRZr; Tue, 18 Oct 2022 08:44:35 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Ms6qR2P06z3rHN; Tue, 18 Oct 2022 08:44:35 +0000 (UTC) (envelope-from kp@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666082675; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s8EM/xqhqXZ87hcx9yRAr9aHt9iKMtKtxOS11/qd5BE=; b=Ng4CrQXOQyP0m/0Xvpv2bqb+/NSYo0pIdZGoz1LA1fRAOyEHnFSiS4cX6VsAgNdIc0xyBD oO4ACZWKdYogn9quaR6NRA8XgI46qnAdPHsa2GOe9bwkkrs2jjh7Az73L2s+UNsM3yvWTK N+rARhlPVWO4rCiMSYoFslQ27aXdBTq70fb6hRBAJ4MLyK3MT0B4Qg1QDKW/lRE4/RMhOK lzixcgeJK7Uk+IpEz1VLSBtYBug0PLbLXErFIrP/n1utFcLt/ZdyHTAV6GpaOFQYUv7hMA glSqKgRxlUSq9H1bqjTc/Q/kstNM0/6NTkI5gbY5qmfzlpoczSPcSkwuR9QGYw== Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (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 (2048 bits) client-digest SHA256) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Ms6qQ6w0lz1Xrr; Tue, 18 Oct 2022 08:44:34 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 32C612E3BC; Tue, 18 Oct 2022 10:44:33 +0200 (CEST) From: Kristof Provost To: Matteo Riondato 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 Date: Tue, 18 Oct 2022 10:44:32 +0200 X-Mailer: MailMate (1.14r5918) Message-ID: <9B65580C-2959-4A01-8386-65E5AA596FC2@FreeBSD.org> In-Reply-To: <20221017173704.d3mvikbc25to6snn@host-ubertino-mac-24f5a28a9493.wired.10net.amherst.edu> 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> List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_2B1CB56D-64E4-4500-ADF1-D33BA8E3C1E0_=" Content-Transfer-Encoding: 8bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1666082675; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s8EM/xqhqXZ87hcx9yRAr9aHt9iKMtKtxOS11/qd5BE=; b=BrsgyKfbbcq/T97UI/+4VKP2QQm/OxjMlRKbLihpCAb0vrqyb2K765r1P9GW/kfaNweob1 7lTZdfjEhIO5vpVu2SjXhLrCVq+dQiXsyzqVObWGSAqaJjKo77L4Ve6TLjxBQ4nyhSrWG8 Fe9SJcsexSHaTnxEgL8oz/YRbDOgUQWa3cSSHVqZC18CDZCnn5pQwQTQ+GUZR9jSo4mvlt uMXQxOywPud6B8z7Ny3FqM8zQMFDkshTDsWdeH+eJXdhZ3MtImrwEMTsLoIkLZhHLXjTwZ ZprbPIU0l/o7P4mGfaWRPXAGNVRH4Lfb7E4IINKYWFotSp6JZcJ45UTfDEbUBg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1666082675; a=rsa-sha256; cv=none; b=JI9cB79GGGUUmd12gVgDYnmgdYy5au2R47Elz9IjejEs0DliIrgHb+Htflb6rk8bHsHIeJ FCEqjA6Fi6++EnEpL08D9K9av2pWvIl5u88RgAcqI6sx8BDKW4xfIVXJYfNnsUdlPUpXTd 0wMfD8O94TuXlOpsr4mWOOg/nnaV0xDI0lPlbJEgkDRdSj2D4p10Z5prxkIJ23eu0waGe0 nrRDCil+OdUWWkkLsijbH1OzHUc2DGKifWUCrMJG0+NfzzMMXRkdmBZgcJer7Gorru9MuU l86UehiisXoGXPfmeXOWOAA9lweoyovT2zAgqhg5bggO0iumyJqMTkEW2lzmkw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --=_MailMate_2B1CB56D-64E4-4500-ADF1-D33BA8E3C1E0_= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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’ve looked at this a bit more, and I am now going to back away >> from the whole anchor thing, and try to pretend I didn’t see any of >> 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’d 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 > case? > > Printing of rules with anchors being broken (I even get a segmentation > fault with 'pfctl -a "*" -sr -vv') makes debugging rulesets very hard. > `pfctl -a "*" -sr` should always produce the expected results, at least as far as I know. I’d be very interested in seeing a test case where that core dumps, because that is indeed very annoying, and might be something I can fix. > Partially, the question I also have is: is printing of rules broken, > or is flushing of rules broken, or a third thing? =) > To the extent that I currently understand this problem I believe the issue is that we’re not always stepping into child anchors to print them. I believe they do get evaluated when the rules are processed. So it’s the printing that’s broken. The flushing is .. not broken, but may not do what you’d expect. When we flush we only flush the root anchor, and other anchors can remain. I think that’s the main source of the strange behaviour I’ve described. Best regards, Kristof --=_MailMate_2B1CB56D-64E4-4500-ADF1-D33BA8E3C1E0_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 away from the whole anchor thing, = and try to pretend I didn=E2=80=99t see any of 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 case?

Printing of rules with anchors being broken (I even get a= segmentation fault with 'pfctl -a "*" -sr -vv') makes debugging rulesets= very hard.


pfctl -a "*" -sr should always produce the expected= results, at least as far as I know.
I=E2=80=99d be very interested in seeing a test case where that core dump= s, because that is indeed very annoying, and might be something I can fix= =2E

Partially, the question I also have= is: is printing of rules broken, or is flushing of rules broken, or a th= ird thing? =3D)


To the extent that I currently understand this problem I = believe the issue is that we=E2=80=99re not always stepping into child an= chors to print them. I believe they do get evaluated when the rules are p= rocessed. So it=E2=80=99s the printing that=E2=80=99s broken.
The flushing is .. not broken, but may not do what you=E2=80=99d expect. = When we flush we only flush the root anchor, and other anchors can remain= =2E I think that=E2=80=99s the main source of the strange behaviour I=E2=80= =99ve described.

Best regards,
Kristof

--=_MailMate_2B1CB56D-64E4-4500-ADF1-D33BA8E3C1E0_=--