From owner-cvs-all Sat Feb 14 19:30:48 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA12133 for cvs-all-outgoing; Sat, 14 Feb 1998 19:30:48 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA12120; Sat, 14 Feb 1998 19:30:45 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id UAA26715; Sat, 14 Feb 1998 20:29:57 -0700 (MST) Message-Id: <199802150329.UAA26715@pluto.plutotech.com> X-Mailer: exmh version 2.0.1 12/23/97 To: Mike Smith cc: "Justin T. Gibbs" , "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:06:29 PST." <199802150306.TAA00685@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 14 Feb 1998 20:27:09 -0700 From: "Justin T. Gibbs" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk >> 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. There is no "prototype mechanism" in the way the system currently works and I don't perceive a large need for this functionality. login.access already deals with most of the compelling cases where this functionality might be beneficial. Going to a single file format increases the complexity of the "parser" in the kernel... I mean are you going to handle reg-exps in your prototypes? Can you ensure that your parser will not crash the kernel 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. A file per node means that parsing is essentially a namei/stat/check operation. 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. Most changes in permission policy on device nodes, with the exception of special chroot environments, tends to open up permissions, not tighten them 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. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message