Date: Sat, 14 Feb 1998 19:06:29 -0800 From: Mike Smith <mike@smith.net.au> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: "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: <199802150306.TAA00685@dingo.cdrom.com> In-Reply-To: Your message of "Sat, 14 Feb 1998 19:31:40 MST." <199802150234.TAA24906@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> The biggest advantages I see in DEVFS are the possibility to eliminate all > of the unit->softc/static array translation cruft that is currently > performed in the kernel as well as remove any device numbering limitations. > Just take a look at all of the 32bit dev_t nonsense in the NetBSD lists to > see how flawed the current approach is. Exactly. > I think that the persistence problem with DEVFS is solvable and if/when it > is proved to be so, why do we need to provide the old mechanism? We don't. And in fact, if we wish to solve the current problems properly, the old mechanism cannot be provided. This is not a bad thing. > Here are my thoughts on the persistence problem: > > 1) Use an underlying file per node, to represent permission and "whiteout" > overrides. The semantics for modification of these files will need some > thought. For instance, if the DEVFS is not mounted on top of these files, > you don't want to allow John Doe to be able to write to them. I don't > think however, as someone once suggested, they should be "invisible". I think that one file per node is wasteful and inefficient. It also fails to provide for prototype entries, as phk raised yesterday. Using two separate files, one for per-node overrides and a second for rules, IMHO, would make for the most efficient approach. When the DEVFS is not mounted on top, these files may be secured or not according to local policy, with an obviously secure default. > 2) To handle special chroot environments (e.g. ftp), provide a special > DEVFS mounting option. This option would essentially say that no matter > what devices exist in the system, only nodes that have a backing file will > be shown. This could, again, be better handled with prototype entries. Write the prototype rules into the mountpoint first, then mount devfs over the top. Obviously, there would have to be a set of "allow" and "deny" rules. > 3) Only root should be able to mount a DEVFS. > > 4) At secure levels above X (0???), additional DEVFS file system instances > cannot be created. All makes sense. -- \\ 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?199802150306.TAA00685>