Date: Mon, 28 Jan 2002 21:45:43 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: Nate Williams <nate@yogotech.com> Cc: C J Michaels <cjm2@earthling.net>, 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> In-Reply-To: <15445.44102.288461.155113@caddis.yogotech.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.)
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020128204542.GA87400>