From owner-freebsd-stable Fri Jan 25 8:48:15 2002 Delivered-To: freebsd-stable@freebsd.org Received: from newman.ucs.mun.ca (newman.ucs.mun.ca [134.153.2.130]) by hub.freebsd.org (Postfix) with ESMTP id C610B37B404; Fri, 25 Jan 2002 08:48:10 -0800 (PST) Received: from plato.ucs.mun.ca (root@plato.ucs.mun.ca [134.153.2.151]) by newman.ucs.mun.ca (8.12.1/8.12.1) with ESMTP id g0PGlvob011003; Fri, 25 Jan 2002 13:17:57 -0330 (NST) Received: from plato.ucs.mun.ca (pdf@localhost [127.0.0.1]) by plato.ucs.mun.ca (8.12.1/8.12.1) with ESMTP id g0PGlvtX005620; Fri, 25 Jan 2002 13:17:57 -0330 (NST) Received: (from pdf@localhost) by plato.ucs.mun.ca (8.12.1/8.12.1/Submit) id g0PGlt76013243; Fri, 25 Jan 2002 13:17:55 -0330 (NST) From: Paul David Fardy Message-Id: <200201251647.g0PGlt76013243@plato.ucs.mun.ca> To: Nik Clayton Date: Fri Jan 25, 2002 05:51:54 AM America/St_Johns Cc: Patrick Greenwell , stable@FreeBSD.ORG Subject: Re: Firewall config non-intuitiveness 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 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 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=; 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 / -- 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