Date: Mon, 16 Feb 1998 16:47:54 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Nate Williams <nate@mt.sri.com> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, Mike Smith <mike@smith.net.au>, "John S. Dyson" <toor@dyson.iquest.net>, Bruce Evans <bde@zeta.org.au>, dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence Message-ID: <Pine.BSF.3.95.980216164658.8949W-100000@current1.whistle.com> In-Reply-To: <199802162305.QAA25582@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It's been agreed by all that a security must is the capacity to dissable new arrivals until the administrator is ready to cope with them. (OPTIONAL!) On Mon, 16 Feb 1998, Nate Williams wrote: > > >The prototype mechanism in the current system is implemented in > > >the /dev/MAKEDEV script. DEVFS as it currently stands moves this > > >prototyping into the kernel, and makes it nonconfigurable. > > > > And most people never modify /dev/MAKEDEV. Instead, they simply chmod/ > > chown devices after they are created by MAKEDEV. In a DEVFS scenario, > > you have the same capabilities. > > Except that with MAKEDEV, you don't get to use the device until you make > it, so you never have any significant point in time where the 'defaults' > aren't OK. When they are created by default, you do if they aren't the > same as the kernel. (Think about non-standard devices, or sound stuff > that isn't 'created' by default until it's used, or better yet > PCMCIA/CardBus hardware.) With MAKEDEV the user doesn't get access to > the device until the administratory explicitly creates it, and when he > does he will also modify the defaults if necessary for that machine. > > With DEVFS, no such 'safety' margin exists, since the device is created > possibly with the administrator realizing it. If you provide a way to modify > the 'defaults', then the administrator can be assured that things will > be as open (or closed) as desired w/out having to modify the kernel > sources. > > Not being generic enough is as bad of a problem as being too generic. > > > Nate > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980216164658.8949W-100000>