Date: Fri Jan 25, 2002 05:51:54 AM America/St_Johns From: Paul David Fardy <pdf@morgan.ucs.mun.ca> To: Nik Clayton <nik@FreeBSD.ORG> Cc: Patrick Greenwell <patrick@stealthgeeks.net>, stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness Message-ID: <200201251647.g0PGlt76013243@plato.ucs.mun.ca>
next in thread | raw e-mail | index | archive | help
On Thu, Jan 24, 2002 at 08:21:50PM -0800, Patrick Greenwell wrote:
>> ... made the mistake of thinking that in order to disable this
>> functionality to allow all traffic that I merely needed to remove
>> the firewall_enable paramater from my rc.conf since firewall_enable
>> is set to NO in /etc/defaults/rc.conf.
>>
>> This did not have the intended result of disabling the firewall,
>> rather a default deny was applied. If firewall_enable is set to NO,
>> wouldn't it make more sense to have the init scripts set
>> net.inet.ip.fw.enable to 0, or am I missing something?
Nik Clayton <nik@FreeBSD.ORG> wrote:
>> I've got a hunch this needs to be a tri-state variable.
>>
>> YES -- Load the firewall rules
>> NO -- Do nothing, default policy is compiled in to the kernel
>> OFF -- Explicitly set net.inet.ip.fw.enable=0
>>
>> or similar.
Is there a precedent for such tri-state variables in the conf files?
It seems to me that "foo_enable" should be strictly "yes/no".
I think I've learned to read "foo_enable" as "Enable foo?" which
seems a good thing to me (intuitive--in a non-Raskinian way :-).
I suppose that accepting "DEFAULT" might be considered a precedent.
But that's not really tri-state: that's defering the value to a second
bi-state variable. "DEFAULT=<yes or no>; foo_enable=DEFAULT"
Would it not be better to have a second "enable" variable?
firewall_enable="NO" # Set to YES to enable firewall functionality
# Set to DEFAULT to defer to kernel
firewall_script="/etc/rc.firewall" # Which script to run to set up the firewall
firewall_script_enable="YES" # Run ${firewall_script} (or NO)
It breaks backward compatibility, but is the broken case useful?
I notice that the useful warning
"Warning: kernel has firewall functionality, but firewall rules are
not enabled. All ip services are disabled."
is printed by /etc/rc.network, but only if ${firewall_enable}=YES.
It might be (or have been) beneficial to pull that out one or two
conditional branches.
Paul Fardy <pdf@mun.ca> / <pdfardy@mac.com>
--
PS It appears that one of mac.com's mail servers isn't listed
in the reverse DNS and hub.freebsd.org rejects my mail. I've
sent e-mail to postmaster@mac.com and hostmaster@apple.com.
But, as postmaster for a university, I'm wondering how well these
specific mailer rules on hub.freebsd.org have been working. How
rare is my problem and how effective is this ruleset in fighting
junk mail? -- just curious
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?200201251647.g0PGlt76013243>