From owner-cvs-all Mon Feb 16 03:58:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA05241 for cvs-all-outgoing; Mon, 16 Feb 1998 03:58:41 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA05212; Mon, 16 Feb 1998 03:58:36 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id DAA06121; Mon, 16 Feb 1998 03:56:17 -0800 (PST) Message-Id: <199802161156.DAA06121@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Justin T. Gibbs" cc: Mike Smith , "John S. Dyson" , bde@zeta.org.au (Bruce Evans), dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence In-reply-to: Your message of "Sat, 14 Feb 1998 20:27:09 MST." <199802150329.UAA26715@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Feb 1998 03:56:16 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > >I think that one file per node is wasteful and inefficient. It also > >fails to provide for prototype entries, as phk raised yesterday. > > There is no "prototype mechanism" in the way the system currently works and > I don't perceive a large need for this functionality. There is, and a number of other people do. 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. This is not good from the point of view of a system where device node arrival is possible and nodes might arrive in an insecure state. > login.access already > deals with most of the compelling cases where this functionality might be > beneficial. How so? Login.access controls login sources, it appears to have nothing for generally handling permissions on arbitrary sets of device nodes. > Going to a single file format increases the complexity of the > "parser" in the kernel... True. But it need not be overcomplex. > I mean are you going to handle reg-exps in your > prototypes? Given the typical format of a device node's name, that's hardly likely. > Can you ensure that your parser will not crash the kernel for > all input? Can you gurarantee that the kernel will not crash for all input? > If you put the parser in "mount_devfs" (ala IPFW), you still > have to come up with a clean, space efficient way to represent these > prototypes since "arrival events" are bound to happen after the initial > mount. As are rule arrivals. As Julian and I discussed, the interface is likely to be via a file-like object in the mounted devfs having similar semantics to the file beneath when the devfs is not mounted. > A file per node means that parsing is essentially a namei/stat/check > operation. It also means that duplicating the node permissions into a new mountpoint requires replication of all of the nodes, and backup requires archiving them all. > No allocated space for mount time rules is required since the > kernel can easily "check a rule" at any time. When new nodes "arrive" > for the first time, their default permissions should be on the secure side. ... and then they can't be used until they are *manually* fixed up. That leaves a large margin for error and user confusion, and no room at all for providing a default state for nodes. > down and if we give the sysadmin the mount option for chroot environments, > there should be nothing stoping them from using it on all instances of > DEVFS if they choose to do so. I never had any intention of proposing such a restriction; indeed the idea behind having only the two files was specifically to make it easier to move the rules around in order to make chrooted devfs mounts manageable. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message