From owner-freebsd-current Sat Feb 10 11:13:19 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA05794 for current-outgoing; Sat, 10 Feb 1996 11:13:19 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA05789 for ; Sat, 10 Feb 1996 11:13:17 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA16261; Sat, 10 Feb 1996 12:08:16 -0700 From: Terry Lambert Message-Id: <199602101908.MAA16261@phaeton.artisoft.com> Subject: Re: FS PATCHES: THE NEXT GENERATION To: jkh@time.cdrom.com (Jordan K. Hubbard) Date: Sat, 10 Feb 1996 12:08:16 -0700 (MST) Cc: KentH@HNS.St-Louis.Mo.US, julian@ref.tfs.com, terry@lambert.org, current@FreeBSD.ORG In-Reply-To: <23357.823938528@time.cdrom.com> from "Jordan K. Hubbard" at Feb 9, 96 11:48:48 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@FreeBSD.ORG Precedence: bulk > > I *strongly* disagree with you. If I change the dev's on my firewall > > I expect 'em to damn well stay changed and the first time they don't > > I first go searching for the person that hacked the firewall, then > > finding nothing, I dump it and rebuild it from scratch assuming that > > I've just been badly beaten at my game. Now you tell me that they won't > > stay that way? I dump it and get a new o/s. > > FWIW, this is almost word-for-word what the folks at USENIX told me > and Julian will almost certainly never convince me that this is a > problem that can be dismissed lightly. I will fight long and hard for > compatibility because I happen to think that I'm 100% right about how > users will feel about this, and if no one else will speak for them, > I will. Jordan, how does dset work? I mean, the kernel has some settings for which devices are to be probed/enabled by default, you change them administratively, and dset makes the changes persistant. I guess it's not conceivable that a similar persistance mechanism could be used for device permissions. Like the following in /etc/rc assures the persistance of pty permissions in the current distribution: # Whack the pty perms back into shape. chmod 666 /dev/tty[pqrs]* Clearly, the /etc/rc file is the wrong place for this (I see it's there -- too bad this isn't a devfs so that this ugly wart wouldn't be necessary). I see no philosophical difference from one administrative override that modifies the default kernel and another that modifies the same file, but operates on different data. Without a prebuilt tool for doing this, you can accomplish exactly the same thing, either within /etc/rc, using mtree, or by modifying the device registration lines on a per driver basis and rebuilding your kernel. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.