From owner-cvs-all Sat Feb 14 19:08:09 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA10061 for cvs-all-outgoing; Sat, 14 Feb 1998 19:08:09 -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 TAA09986; Sat, 14 Feb 1998 19:08:02 -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 TAA00685; Sat, 14 Feb 1998 19:06:30 -0800 (PST) Message-Id: <199802150306.TAA00685@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Justin T. Gibbs" cc: "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 19:31:40 MST." <199802150234.TAA24906@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 14 Feb 1998 19:06:29 -0800 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > 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