From owner-freebsd-stable Mon Jan 28 12:46: 0 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by hub.freebsd.org (Postfix) with ESMTP id B24AC37B400 for ; Mon, 28 Jan 2002 12:45:49 -0800 (PST) Received: from d1o913.telia.com (d1o913.telia.com [195.252.44.241]) by mailc.telia.com (8.11.6/8.11.6) with ESMTP id g0SKjm403553 for ; Mon, 28 Jan 2002 21:45:48 +0100 (CET) Received: from falcon.midgard.homeip.net (h185n2fls20o913.telia.com [212.181.163.185]) by d1o913.telia.com (8.8.8/8.8.8) with SMTP id VAA14152 for ; Mon, 28 Jan 2002 21:45:45 +0100 (CET) Received: (qmail 87454 invoked by uid 1001); 28 Jan 2002 20:45:43 -0000 Date: Mon, 28 Jan 2002 21:45:43 +0100 From: Erik Trulsson To: Nate Williams Cc: C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <20020128204542.GA87400@student.uu.se> Mail-Followup-To: Nate Williams , C J Michaels , charon@seektruth.org, dsyphers@uchicago.edu, imp@village.org, stable@FreeBSD.ORG References: <200201271757.g0RHvTF12944@midway.uchicago.edu> <1617.216.153.202.59.1012240332.squirrel@www1.27in.tv> <20020128192930.GA86720@student.uu.se> <15445.44102.288461.155113@caddis.yogotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15445.44102.288461.155113@caddis.yogotech.com> User-Agent: Mutt/1.3.25i Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, Jan 28, 2002 at 12:53:42PM -0700, Nate Williams wrote: > > Note that "do not enable firewall" (which is implied by firewall_enable="NO") > > is *not* equivalent to "disable firewall". > > Maybe we're having an English language question. Probably. Natural languages are notoriously ambiguous and easy to misinterpret. > > If something isn't enabled, doesn't that imply that it's disabled? Last Correct so far. > I checked, enabled/disabled were binary operations. No, they are binary states. An operation is someting you do. (Enabled/disabled are states. Enable/disable are operations.) > If I enable the clutch in my car, my car moves (assuming it's in gear). > If I disable it, the power is no longer going to the drive wheels. > > It's either enabled or disabled. There is no 'in-between' state. > (Well, unless you're riding the clutch, but that's not considered a > valid state, since the behavior is undefined, as well as bad for your > clutch. :) Never heard about fuzzy logic? :-) There are four possible functions (or operations) taking a binary value to another binary value. (I.e. a function f(x) from {0,1} -> {0,1}) You can: 1) Map all input values to 1 2) Map all input values to 0 3) Return the input unchanged 4) Return logical inverse of the input. Now let us represent 'enabled' by 1 and 'disabled' by 0 Then I would say that "to enable something" corresponds to function 1), i.e. to move it to the enabled state regardless of what state it was in previously. Similarily "to disable something" corresponds to function 2) Now what should "do not enable it" correspond to? It obviously can't be 1), and 4) seems quite counter-intuitive and (when talking about firewalls) not very useful. Remains 2) and 3) where 3) is the current behaviour for firewalls and 2) the proposed one. To me "do not enable" means that we should not change the state to 'enabled'. But if we already are in the enabled state then what? Since letting it remain in the current state does not constitute *changing* the state to 'enabled' this is a perfectly good interpretation of "do not enable". Now, changing the state to 'disabled' also fits the decription "do not enable", but IMO changing the state unless explicitly asked to do so is a bad idea. That is why I (and others before) have said that a tristate variable (corresponding to functions 1), 2) and 3) above) is probably the best solution. (With 3) being the default.) (Function 4) is fairly useless for this so we can skip it.) Another possiblity is changing the name. For example using "firewall_enabled" instead of "firewall_enable" To me that means "should the firewall state be in the 'enabled' state" rather than "should we move the firewall state to 'enabled'" (I.e. describing the state rather than the operation.) In either case, changing the meaning of 'firewall_enable="NO"' should probably not be done in -STABLE to avoid messing things up for people who depend on the current behaviour. (Since changing the behaviour as proposed would, for some configurations, mean a lowered security this is extra important for this case.) -- Erik Trulsson ertr1013@student.uu.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message