From owner-svn-src-all@freebsd.org Tue Apr 3 16:12:34 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7C4BF59B11; Tue, 3 Apr 2018 16:12:33 +0000 (UTC) (envelope-from srs0=rwrb=gy=freebsd.org=kp@codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5A8BB851D0; Tue, 3 Apr 2018 16:12:30 +0000 (UTC) (envelope-from srs0=rwrb=gy=freebsd.org=kp@codepro.be) Received: from [10.0.2.164] (ptr-8ripyyg3pshqansoctr.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:701f:5a9f:25d:ceef]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id DE0159503; Tue, 3 Apr 2018 18:12:27 +0200 (CEST) From: "Kristof Provost" To: "Gleb Smirnoff" Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r331546 - head/etc/rc.d Date: Tue, 03 Apr 2018 18:12:26 +0200 X-Mailer: MailMate (2.0BETAr6106) Message-ID: <15CEFBCD-8875-438D-B370-3468DC637A53@FreeBSD.org> In-Reply-To: <20180403160646.GE1917@FreeBSD.org> References: <201803260936.w2Q9aMfD082758@repo.freebsd.org> <20180402220430.GD1917@FreeBSD.org> <4F543A96-C6B1-4FF0-A501-BC6C7FD3F26A@FreeBSD.org> <20180403160646.GE1917@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 16:12:34 -0000 On 3 Apr 2018, at 18:06, Gleb Smirnoff wrote: > On Tue, Apr 03, 2018 at 08:49:09AM +0200, Kristof Provost wrote: > K> On 3 Apr 2018, at 0:04, Gleb Smirnoff wrote: > K> > I just want to note that this is a huge change of behaviour > K> > of pf(4) for a user. Over a decade everybody has been used > K> > to the difference between "reload" and "resync". > K> > K> There is no difference. r330105 removed the ‘$pf_program -Fnat > -Fqueue > K> -Frules -FSources -Finfo -FTables -Fosfp’ line, but this never > K> actually did what the author thought it did. > K> pfctl only ever performed the last ‘-F’, not all of them, so > all > K> this ever did was flush the OS fingerprints information. Clearly > K> that’s not what was intended. > K> > K> pf never actually breaks existing connections, because existing > states > K> keep using the rule that created them, regardless of the current > rules. > K> It wouldn’t have broken connections with resync either. A > K> ‘restart’ will, because ‘start’ does ‘pfctl -F all’. > K> > K> If the flush had actually done what was intended it’d arguably > have > K> been a security issue, because reloading rules would then (briefly) > open > K> the firewall, allowing all traffic to pass and establish state. > > Hmm, may be I am wrong, but back when I was actively working with pf, > the "reload" command would break the ssh connection I am using, so > I have taught myself to use "resync". > Apparently reload used to have a ‘${pf_program:-/sbin/pfctl} -Fa’, which would have flushed everything and killed your connection. That was removed back in 2005 (April 4th, so pretty much exactly 13 years ago), and replaced by the erroneous ‘-Fnat -Fqueue -Frules -FSources -Finfo -FTables -Fosfp’ version. Regards, Kristof