From owner-freebsd-arch@FreeBSD.ORG Thu Jul 17 01:43:26 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76B0037B401 for ; Thu, 17 Jul 2003 01:43:26 -0700 (PDT) Received: from mail.cyberonic.com (mail.cyberonic.com [4.17.179.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 575F643FAF for ; Thu, 17 Jul 2003 01:43:25 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (node-40244c0a.sfo.onnet.us.uu.net [64.36.76.10]) by mail.cyberonic.com (8.12.8/8.12.5) with ESMTP id h6H9BQcU020438 for ; Thu, 17 Jul 2003 05:11:26 -0400 Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.9/8.11.6) id h6H8hX5V077780 for freebsd-arch@freebsd.org; Thu, 17 Jul 2003 01:43:33 -0700 (PDT) (envelope-from jmg) Date: Thu, 17 Jul 2003 01:43:33 -0700 From: John-Mark Gurney To: freebsd-arch@freebsd.org Message-ID: <20030717084333.GB35337@funkthat.com> Mail-Followup-To: freebsd-arch@freebsd.org References: <20030717080805.GA98878@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030717080805.GA98878@dragon.nuxi.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: Things to remove from /rescue X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2003 08:43:26 -0000 David O'Brien wrote this message on Thu, Jul 17, 2003 at 01:08 -0700: > - ipfw & natd & ipf & ipfs & ipfstat & ipmon & ipnan, why would one needs > these? /rescue is to fix a borked /, not replace PicoBSD. ipfw I can see as useful. If you have a kernel that defaults to closed, and you need to access the network, then this is a problem. If we had a loader tunable to make a closed firewall open, then this wouldn't be needed, but then we introduce the fun security hole of /boot/loader.conf munging, which is minor... if someone can modify /boot/loader.conf, you have bigger fish to fry.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."