Date: Sat, 14 Feb 1998 20:27:09 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Mike Smith <mike@smith.net.au> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, "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: <199802150329.UAA26715@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 14 Feb 1998 19:06:29 PST." <199802150306.TAA00685@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802150329.UAA26715>