Date: Wed, 30 Jan 2002 23:21:49 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: "Jacques A. Vidrine" <n@nectar.cc>, Matthew Dillon <dillon@apollo.backplane.com> Cc: <freebsd-stable@FreeBSD.ORG> Subject: Re: Proposed Solution To Recent "firewall_enable" Thread. [Please Read] Message-ID: <p05101226b87e6b0f9966@[128.113.24.47]> In-Reply-To: <20020130202356.A47852@hellblazer.nectar.cc> References: <JI75GAYSTRA5PJZYUKGON75TOB88.3c586114@VicNBob> <200201310042.g0V0g3255325@apollo.backplane.com> <20020130202356.A47852@hellblazer.nectar.cc>
next in thread | previous in thread | raw e-mail | index | archive | help
At 8:23 PM -0600 1/30/02, Jacques A. Vidrine wrote:
>On Wed, Jan 30, 2002, Matthew Dillon wrote:
> > ... In which case it is utterly trivial to configure rc.conf such
> > that the ipfw rules aren't changed. You don't have to make 'NO'
> > do nothing in order to accomplish that.
> >
>> NO in this context is very clear: I don't want firewall rules, not
>> even the default deny. It should put the computer into the same
>> effective state no matter how the kernel is compiled.
>>
> > I find it quite unbelievable that people are even arguing over
> > this. It's as though some people WANT to make rc.conf as
> > obfuscated and confusing as possible.
For what it's worth, I agree with Matt here. Several times I've
started to write a message which says so, and it always ends up much
too long. I find it so unbelievable that the current behavior is
being defended as "logical" that I can't imagine how much of my own
thinking must need to be explained to show why I think the current
behavior is wrong and user-hostile (for an "average" user -- in my
opinion any "firewall-expert" user will handle this no matter what
options we define).
So, to save everyone time, let's make believe there is a very
long and impassioned justification at this point:
[blah blah blah, as a support person, blah blah, consistent
naming for options in rc.conf, blah blah blah, I'm too sexy
for my shirt, blah blah blah, etc, etc]
>If you are talking about changing it in -STABLE:
> Forget it. We're not going to have `firewall_enable=NO' suddenly
> result in turning off firewall functionality. Never mind that I
> think that's a silly interpretation -- it's just that it is too
> dangerous.
Let me further pretend that the above argument was so excellent, that
even people who don't agree will say 'we *might* allow this, if you
can change the meaning without causing massive problems for users'.
I suggest that the main difference of opinion is what the phrase
"firewall is disabled" brings to mind (in different minds). To me,
that means "I have no firewall", and not "I have a firewall which
is not letting any packets through". Ie, I think a firewall service
is one which *blocks* packets, while others seem to think of a
firewall as something which *allows* packets through. Thus, if
the firewall is disabled, I expect all packets to get through, while
someone else would expect no packets to get through.
I think we could have two settings, right next to each other, in
/etc/defaults/rc.conf:
firewall_enable=NO # NO means 'no packets are blocked'
firewall_rules_enable=YES # NO means that if the firewall is up,
# then all packets will be blocked,
# ignoring any 'rules' you have defined.
If anyone sees that change go by in mergemaster, and they do depend
on the present behavior, and those comments (or something better
than those) do not ring an alarm in their heads, then I would be
either surprised or disturbed.
Maybe even this is too drastic a change for -stable, although I'd
it would work. I wouldn't push for this, but I have to believe
there are few people who are running *-production-* systems where
they depend on the present behavior of 'firewall_enable=NO', and
that the present behavior *will* cause trouble for -stable users
who want to "turn off the firewall just to test something".
disclaimer: I missed the first message in this thread (the one
which might have given a proposed solution), so I don't know if
my idea is any different than that one. I also can't seem to
find the first message thru the mailing-list-search web page...
Apologies if this is just a repeat of an earlier idea.
--
Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
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?p05101226b87e6b0f9966>