Date: Mon, 16 Feb 1998 03:56:16 -0800 From: Mike Smith <mike@smith.net.au> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Mike Smith <mike@smith.net.au>, "John S. Dyson" <toor@dyson.iquest.net>, bde@zeta.org.au (Bruce Evans), dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence Message-ID: <199802161156.DAA06121@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 14 Feb 1998 20:27:09 MST." <199802150329.UAA26715@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802161156.DAA06121>