Date: Tue, 14 Oct 97 17:14:21 -0700 From: "Studded" <Studded@dal.net> To: "Chad R. Larson" <chad@freebie.dcfinc.com>, "Daniel O'Callaghan" <danny@panda.hilink.com.au> Cc: "freebsd-stable@freebsd.org" <freebsd-stable@FreeBSD.ORG> Subject: Re: Problem with rc.conf/rc.firewall Message-ID: <199710150014.RAA11383@mail.san.rr.com>
next in thread | raw e-mail | index | archive | help
On Tue, 14 Oct 1997 20:19:27 +1000 (EST), Daniel O'Callaghan wrote:
>On Mon, 13 Oct 1997, Studded wrote:
>
>> the kernel from the same kernel config file I used with the
>> 2.2-970901-STABLE sources previously that included ipfw. I set the
>> firewall option to YES in rc.conf, and set the type to OPEN.
>>
>> A gold star to anyone who has already spotted the problem, the
>> rc.firewall script expects "${firewall_type}" = "open", not OPEN, and
>> it bombed out. IMO putting the firewall_type option rc.conf is a big
>> mistake. It loses big in functionality what little it makes up for in
>> convenience, especially when I'm 600 miles from the machine.
>
>My first proposal to committers was that firewall_type would be in
>rc.firewall, but it was pointed out that the model being progressively
>adopted is to put more config into rc.conf and less into other rc.*.
That's fine for options that don't require another file for reference,
and after getting over my awkwardness with the transition, it's actually a
welcome change.
>I can't really see any advantage in putting firewall_type in rc.firewall,
>other than that it would force the user to read (or at least see) the
>first lines of rc.firewall.
I can see two on the surface, the first being that it will help prevent
errors like mine (about which I've received several private letters saying that
I'm in good company). Secondly in the case of options like ipfw, your model
requires a person to open rc.conf, then open rc.firewall, then go back to
rc.conf. My suggestion saves a step. Chad Larson pointed out a third
advantage in a mail to this list, namely, "It also means packages can be added
without performing a merge into a main file (put 'em in /usr/local/etc/rc.d)."
> But the comment in rc.conf next to
>firewall_type clearly informs the user to see rc.firewall for a fuller
>explanation, and lines 5-15 of rc.firewall list the available values for
>rc.firewall. I grant the case-sensitivity is awkward, and I'll look into
>it, but firewall_type will stay in rc.conf for the moment.
Ok, if that is to be a firm policy, I will submit a PR with diffs that include
some clarification.
>> little-used options from an already crowded rc.conf. Suggestion number
>> two is to make the type open BY DEFAULT, and let the person change it
>> if need be. There is really no reason to set up stumbling blocks that
>
>Two years ago, when I submitted patches for the TCP fragment offset bug,
>prompting Poul-Henning Kamp to rewrite most of the ipfw code, there was a
>function which allowed the user to set the default "policy" to open or
>closed. PHK changed this to default closed all of the time to lower the
>chances of a machine being set up which was "open" while the administrator
>thought it was "closed".
Hmmm, I think that if someone is intentionally wanting to close off a
machine, they would be a lot more rigorous about testing it than a person that
wants to enable the firewall code to do accounting or experimentation. A
default closed policy is just asking for trouble IMO, and while it might make
some sense from a programming standpoint, I don't see any reason not to
make the scripts we provide more user friendly.
>I can't count the number of times I've built a
>kernel, rebooted, and been unable to telnet to the machine. I'm a slow
>learner, I guess.
Well, I got bit by this the first time I tried it, so you are in good
company. :) What frustrated me here is that I know better now, and was
extremely upset to have been 'fooled' by something that on its face looked
like it would have worked.
> Rather than change the default policy I changed
>rc.network so that it would print warnings on the console if a kernel with
>firewall functionality was booted and there were no appropriate settings
>in rc.conf.
In the course of preparing my letter yesterday I looked hard at the rc*
scripts. You did an excellent job of including appropriate error checking, but
I'm 600 miles away from the console.
> I can't think of anything better to do than that, myself,
>but I'm open to suggestions (other than "default policy open").
Well, I would think that leaving the kernel functionality as default
closed, but setting up the scripts so that it opens up the machine (and prints
appropriate warnings?) is a good compromise. One error is reversible
remotely, and easy to test. The converse is not.
Finally, I'm not shooting the messenger here, and I appreciate Mr.
O'Callaghan's time in providing an explanation.
Doug
*** Proud operator, designer and maintainer of the world's largest
*** Internet Relay Chat server. 4,168 clients and still growing. :-)
*** Try spider.dal.net on ports 6662-4 (Powered by FreeBSD)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710150014.RAA11383>