Date: Sat, 10 Feb 1996 12:08:16 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: KentH@HNS.St-Louis.Mo.US, julian@ref.tfs.com, terry@lambert.org, current@FreeBSD.ORG Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602101908.MAA16261@phaeton.artisoft.com> In-Reply-To: <23357.823938528@time.cdrom.com> from "Jordan K. Hubbard" at Feb 9, 96 11:48:48 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602101908.MAA16261>