From owner-freebsd-arch Fri Jan 1 14:03:11 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA00531 for freebsd-arch-outgoing; Fri, 1 Jan 1999 14:03:11 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA00523 for ; Fri, 1 Jan 1999 14:03:08 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id XAA00855 for ; Fri, 1 Jan 1999 23:02:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA88406 for freebsd-arch@freebsd.org; Fri, 1 Jan 1999 23:02:44 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA03366 for ; Thu, 31 Dec 1998 06:08:12 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id PAA94810 for ; Thu, 31 Dec 1998 15:07:17 +0100 (CET) To: arch@FreeBSD.ORG Subject: DEVFS, the time has come... From: Poul-Henning Kamp Date: Thu, 31 Dec 1998 15:07:17 +0100 Message-ID: <94808.915113237@critter.freebsd.dk> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ... to make up our mind about it. There are a number of options open for us, and to make sure we talk about the substance let me stress once and for all that this dicussion should be about the >concept< of a devfs, not the code currently in the tree. Once concensus has been reached about what and how a DEVFS should be and react, we can start to study the code in the tree to see if it fits or what it will take to get a devfs that does. DEVFS, HERITAGE, CONCEPT and ADVANTAGES: I talked to Dennis Ritchie about the history of device nodes (CHR/BLK) when I ate breakfast with him in New Orleans. Orginally it was very crude but simple: Inode number 7 was the printer, 8 was the disk, and so on. The root-dir was around 40 at the time. This soon became a problem, so the device nodes were introduced, and we've had them ever since. Device nodes are a shortcut from one namespace (filesystem) to another (cdevsw/bdevsw arrays of device drivers). There is according to Dennis Ritchie no compelling reason to have a separate namespace for anything, if you could put it in the filesystem (plan#9 anybody ?) So what a devfs does is to remove the cdevsw and bdevsw namespaces of device drivers and instead attach not device drivers but instances of devices into the filesystem directly. The advantages of having a DEVFS is trying to solve are the following: 1. Static mapping of major devices must be maintained, this means that 3rd party drivers need to be catalogued and assigned numbers for, and major numbers are a limited resource: there are only 256 of them. 2. Dynamic creation of the needed device nodes, instead of magic shell scripts (MAKEDEV), such that the found devices are available in /dev, and if the device is not there on the next boot, the nodes in /dev are gone again. This is a major tickbox item for people working on Plug&Play, Cardbus, PCMCIA and other dynamic configuration technologies. 3. Avoid the NFOOBAR definitions in the drivers. A Devfs would allow the device driver to attach sufficient information to the vnode that it can find both its "softc" structure and a unit number from the vnode. Currently only the minor device number is available, and that only allows the unit number to be found, the softc struct must be found by taking (a subset of) the minor number as an array index. DEVFS will also remove the need to check the validity of the minor number in the drivers. 4. Clone devices. Rather than define 64 ptys in the system, the system should make a new ones on demand. This is hard, if not downright impossible, to do if you have to mknod something to be allowed to use the thing. There is no doubt that the sources will be cleaner and have less implicit cross dependencies with a well implemented DEVFS; for instance the code in UFS which special cases device nodes can be removed. There are some issues relating to devices and chroot jails, but they are well understood and no major trouble to implement, and I hope we can just ignore them in this discussion for now, as they are a subset of the general problems, and present no new or unique aspects of these problems. I don't currently know of anybody disagreeing in any of the above, but feel free to raise arguments against it if you have any. The PROBLEM: The sticky issue about DEVFS, at least in FreeBSD, is called "persistence". NON-PERSISTENT DEVFS: A "non-persistent" devfs boots up with all found devices visible, (probably mode 0600 root.wheel, 0700 for directories) and a script in /etc/dev.rc will contain the policy for the devices: chmod 660 cua* ; chown uucp.dialer cua* chmod 600 tty[dil]* ; chown root.wheel tty[dil]* chmod 640 fd[0-9]* ; chown root.operator fd[0-9]* ... If you remove a device, it's gone. No way to get it back short of a reboot, and it will be back after the next reboot if the driver is there and finds its hardware, so to remove a device as a policy, you would need to put the rm command in /etc/dev.rc. If you "whiteout" a device, you can get it back with "undelete" and don't need a reboot for it. You can create symbolic and hard links and directories in the DEVFS, but they will be gone on the next reboot, so if you want them around all the time, put them /etc/dev.rc There are no need for any special userland tools. I belive this completely decribes all aspects of a non-persistent DEVFS. PERSISTENT DEVFS: A "persistent" devfs will use some kind of stable storage to track the devices with. First time a device is found, the driver will suggest what mode, owner and group to set on the device. If root goes into the filesystem and does chmod 600 cua* the currently found cua* devices will get this new mode, and will have that mode also after a reboot. Including the case where for half a year the hardware is not there and then suddenly some hardware comes back that fits the bill. Once recorded in the persistence database, there is no way to say "restore defaults mode/owner/group" short of setting it manually. If a new cua device appears, it will still come up with the default driver based permissions, the wildcard aspect of the above command is not recorded, so it is left to the root to manually to enforce his policies. If a device is removed, it will not come back after reboot, so undelete will have to work on removed as well as whiteout'ed devices, effectively making whiteout and unlink the same thing. You can create symbolic and hard links and directories int he DEVFS, and they will be there after reboot. Implementing the peristence in the filesystem is messy, intricate and will take up significant amounts of code. SOME of the issues not addressed in this description: * format of persistance database: ascii file, binary file shadow inodes ? * how to manually list/edit the persistance database ? (tradeoff between ascii parsing code in the kernel vs. specialized reading/writing/editing userland tools.) * modifying the persistance databse for devices not currently found. (as above for specialized tools) * garbage collecting the persistance database. (ditto) * What happens if eg a symlink in the database collides with a newfound device, which entry takes precedence ? * If the persistance database lives in a filesystem, how does the kernel locate it at boot time ? HISTORY: We have had a DEVFS implementation in the tree for 32 months by now. That means from before 2.0.5 was released. The reason we still don't have a DEVFS as standard is that this persistence vs. non-persistence has not been sorted out. It is high time to get this thing settled and move on. OPINION: My personal preference is to take a non-persistent DEVFS. I have never changed the mode or deleted something in a /dev directory without it being a matter of policy. I think any such policy is far better expressed in a shell script run at boot time, where I can use all the facilities of the shell to implement my policy. Having my policy in only one place (unless I myself choose to split it), in a well known form (shell script), where I can put comments on it, and even have it under version control makes me feel good. In particular I like the idea of having wildcard names help make sure my policy also covers any devices added later in time. I can trust the contents of /dev to be in a known and well defined state after a reboot, a state which is conceptually easy to understand and readable in standard syntax for the user. No new tools to learn and know about. I do not feel as confident this would be the case with a persistent DEVFS. I don't like the concept of "shadow databases" expressed through in pseudoform through another database mechanism. I would need to be able to edit or at the very least read the persistence database (sound of agonized cries from AIX users heard in the background). How would I edit an entry in the persistance database for a device I do not currently have in my system ? What happens if I edit the database and somebody else does a chown at the same time? Can I add dormant entries to the database so that any devices appearing later will be set according to my policy? Can I use wildcards for it? It sounds to me like it will be much harder to implement a policy and enforce it, for a persistent DEVFS. It is obviously out of the question to implement the full shell syntax in the kernel, so either we need a special userland process to translate to and from a standard format, or a special toolset to list/edit the binary database. We're in essence talking about adding another namespace, a prospect that makes removing the cdevsw/bdevsw namespace pretty pointless in my book. How about the case where people try out some gadget, forgets about it for a number of months and buy some other gadget instead which the same driver recognizes, then sudenly some old stuff appears out of nowhere which may not even apply to that device, and since the device is there in the database, not even the device driver gets a chance to say what it feels about the issue ? Or even worse the device was removed so the "new" hardware looks like it doesn't work because nothing shows up in /dev ? I'm not fielding the support line on this issue. The fact that it is so much simpler to express the functioning of a non-persistent DEVFS, that so many so thorny issues are tangled up in the persistent DEVFS, makes me think that any advantages of a persistent DEVFS (I see none) are run over, rolled flat, scraped up and thrown out by the Keep It Simple Principle. How many people would ever know the difference anyway? Very few, I presume. I think most people stick with the default permissions, and the few who don't probably know what they are doing. They will therefore be perfectly capable of getting either of the two models to do what they want, maybe with the same bias as me that having a shell script to do it in is both cleaner and easier. Summary: I cannot see who in our user community will benefit from persistance in DEVFS, I don't see what benefits it brings, and I think it is overly complicated hard to implement right and errorprone in action. [My only concern with a non-persistent DEVFS is the permissions on device nodes that appear due to an event (e.g, a card insertion), and I think the can be adequately addressed by having a flag for a DEVFS mount that stop new nodes from automatically appearing in that instance of DEVFS. -EE] -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 16:45:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA15946 for freebsd-arch-outgoing; Fri, 1 Jan 1999 16:45:49 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA15940 for ; Fri, 1 Jan 1999 16:45:47 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA02176 for ; Sat, 2 Jan 1999 01:45:24 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA89130 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 01:45:23 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.117]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA10100; Fri, 1 Jan 1999 15:57:26 -0800 (PST) (envelope-from chuckr@mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.1/8.8.5) with ESMTP id SAA34769; Fri, 1 Jan 1999 18:55:41 -0500 (EST) Date: Fri, 1 Jan 1999 18:55:40 -0500 (EST) From: Chuck Robey To: Poul-Henning Kamp cc: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-Reply-To: <94808.915113237@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 31 Dec 1998, Poul-Henning Kamp wrote: Poul, that was a *great* summary. I'm not going to quote it (it's pretty big) but anyone who missed it, I have a copy and will keep it around for the length of this thread's discussion, so just mail me and ask for it. Anyhow, I want to take on two points, persistence vs. non-persistence, and default values. I know default values for things are not important if non-persistence is chosen, but since the point is raised in both the persistence and non-persistence parts of your arguments, I think I want to raise it here. First, Poul, will you agree that the opinion of the great majority of developers want persistence? I clearly remember a post from a while back, from Jordan at some convention, where he mentions being buttonholed by a number of very influential folks, all of which expressed strong pro-presistence arguments. I know that you brought up your same position at that time (you've been pretty consistent), but wasn't persistence conceded to be an absolute requirement for a DEVFS? To take it one step further, wasn't one of the main reasons for the non-acceptance of our last devfs (not the only reason, but a main reason) it's lack of a strategy for implementing persistence? [I'm trying hard not to inject any trace of sarcasm here at all, please do me the favor of giving me the benefit of doubt, if I mess up some wording and it seems like I'm being cute or something]. If anything I said above is inaccurate or you feel I'm wrong, I'd like to know. If you want, I'll even try to track down that old post from Jordan ... it's probably 2-3 years old by now. Anyhow, moving to the lack of defaults ... you claim that there is no method of restoring default values to a device, once that device has been modified in the persistence database. I disagree. While I don't agree with your statement that all modes and permissions for everything in /dev are a matter of policy, I *would* agree that default values for stuff in /dev are a matter of policy. As such, default values could very easily be handled, couldn't they, in a number of different ways, in fact. It could be done in ASCII files (RO files, not modifiable), or the drivers themselves could store such stuff, and regurgitate it on ioctl calls, right? It could even be done via sysctl, although that strikes me as a bit weird. Restoring defaults to a persistence database then wouldn't seem to be all that terribly hard. You're better at that part than I am, maybe if you made that part a little clearer, I'd see what the roadblock really is. BTW, things like links, that I couldn't deal with, I'm just talking about modes and permissions. I think that's all that needs defaults, right? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) (301) 220-2114 | and jaunt (NetBSD). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 16:53:45 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA16558 for freebsd-arch-outgoing; Fri, 1 Jan 1999 16:53:45 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA16553 for ; Fri, 1 Jan 1999 16:53:43 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA02247 for ; Sat, 2 Jan 1999 01:53:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA89162 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 01:53:20 +0100 (MET) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA13792 for ; Fri, 1 Jan 1999 16:20:48 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA11823 for freebsd-arch@FreeBSD.ORG; Sat, 2 Jan 1999 01:20:24 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id BAA11374; Sat, 2 Jan 1999 01:05:01 +0100 (MET) (envelope-from j) Message-ID: <19990102010459.42125@uriah.heep.sax.de> Date: Sat, 2 Jan 1999 01:04:59 +0100 From: J Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Reply-To: Joerg Wunsch References: <94808.915113237@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <94808.915113237@critter.freebsd.dk>; from Poul-Henning Kamp on Thu, Dec 31, 1998 at 03:07:17PM +0100 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Poul-Henning Kamp wrote: > I talked to Dennis Ritchie about the history of device nodes > (CHR/BLK) when I ate breakfast with him in New Orleans. :-)) Nice sentence, too bad I haven't been able to attend in NO myself... > The advantages of having a DEVFS is trying to solve are the following: Violent agreement. > NON-PERSISTENT DEVFS: Let me add here for those who don't know the story yet, I had the opportunity to work with a system with a non-persistent DEVFS quite some years ago. The overall experience was very positive. The system in question was DG/UX, Data General's Unix version running on their AViiON class of machines, some m88k-based workstation/server series. DG is mostly down these days, concentrating on things like RAID arrays for Winsucks. Too bad, i've seen source code of the DG/UX kernel, and think it was a well-written system. My remembrance is fading, but I believe it took me more than one year to actually even _realize_ DG/UX was using a DEVFS. Count this as an argument for them having done the job very well. Again, their DEVFS didn't have any form of persistance, everything regarding device ownership and permission tweaking was done in some rc script. (The kernel had hard-coded ideas of the initial device permission bits, so something like /dev/null always came out world-writable even with no rc script running so far.) > If you remove a device, it's gone. No way to get it back > short of a reboot, and it will be back after the next reboot > if the driver is there and finds its hardware, so to remove > a device as a policy, you would need to put the rm command > in /etc/dev.rc. If you "whiteout" a device, you can get > it back with "undelete" and don't need a reboot for it. I don't see any form of an implementation for `whiteout' and `undelete' so far. I don't particularly like the idea that you can thus destroy a device access point accidentally. I'd like to see some method for the sysadmin to tell the kernel to `go back and re-establish its idea of the DEVFS'. Speaking in implementation details, it could be another option bit to reboot(2), with another hardlink to reboot(8), like perhaps /sbin/reconfigure. Perhaps this should only go so far to re-established any device node (or its substitute) that has been removed, without resetting ownership and/or permissions on things that are still alive. > SOME of the issues not addressed in this description: > > * format of persistance database: ascii file, binary file > shadow inodes ? If at all (readers might notice I'm not much a fanatic of persistence here ;), then it should be an ASCII file somewhere. By no means, it should be recorded in some unmanipulatable form. I could also imagine of some `unionfs' layer you could mount separately so to see what its current contents is. However, I believe this will only complicate things. > We have had a DEVFS implementation in the tree for 32 months by > now. That means from before 2.0.5 was released. The reason we > still don't have a DEVFS as standard is that this persistence vs. > non-persistence has not been sorted out. It is high time to > get this thing settled and move on. Well, one question sideways: does this mean all the problems with disks entered after boot-time have been resolved in the existing implementation? I. e., I can say `camcontrol rescan all' (or scsi -r on an older system), and it will pick up anything like dreadful fdisk tables and BSD partition tables without a whisper? Last time i looked, this wasn't the case, and my attempts to walk down the code and get it working (on a NFS-booted machine, should that matter) weren't all that successful. [This does not presently work. Julian had/has some partially finished code to fix it. -EE] > OPINION: > > My personal preference is to take a non-persistent DEVFS. Mine too, but that should have become obvious so far. Thus, I fully support your reasoning as you explained in the `non- persistent' section. Persistency aspects: > I would need to be able to edit or at the very least read the > persistence database (sound of agonized cries from AIX users heard > in the background). How would I edit an entry in the persistance > database for a device I do not currently have in my system ? What > happens if I edit the database and somebody else does a chown at > the same time? Stop the devfsd, edit the database, restart devfsd. > Can I add dormant entries to the database so that > any devices appearing later will be set according to my policy? That should be possible, but you're right, it will add complexity. It should by no means go into the kernel. > It is obviously out of the question to implement the full shell > syntax in the kernel, so either we need a special userland process > to translate to and from a standard format, or a special toolset > to list/edit the binary database. One of the major proponents of a persistent DEVFS was Justin, last time we've been talking about it. It seems Justin's opinion is now also to put all this out to userland, into something like a devfsd. One disadvantage of a devfsd is that it needs to remain in-core all the time, or danger of deadlocks could arise. (IMHO) > How about the case where people try out some gadget, forgets about > it for a number of months and buy some other gadget instead which > the same driver recognizes, then sudenly some old stuff appears > out of nowhere which may not even apply to that device, and since > the device is there in the database, not even the device driver > gets a chance to say what it feels about the issue ? In AIX, it would have become instance #1 for the new gadget, with keeping the old instance #0 in mind for eternity. :-) But point taken, you're right. It was a pain in the butt to move some Ethernet card around from one MCA slot to another in AIX. > How many people would ever know the difference anyway? Very few, > I presume. I agree. See my experience report with DG/UX. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 17:34:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20286 for freebsd-arch-outgoing; Fri, 1 Jan 1999 17:34:09 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20281 for ; Fri, 1 Jan 1999 17:34:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id CAA02825 for ; Sat, 2 Jan 1999 02:33:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA89775 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 02:33:43 +0100 (MET) Received: from implode.root.com (root.com [208.221.12.98]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18805 for ; Fri, 1 Jan 1999 17:18:21 -0800 (PST) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id RAA16295; Fri, 1 Jan 1999 17:17:35 -0800 (PST) Message-Id: <199901020117.RAA16295@implode.root.com> To: Joerg Wunsch cc: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 01:04:59 +0100." <19990102010459.42125@uriah.heep.sax.de> From: David Greenman Reply-To: dg@root.com Date: Fri, 01 Jan 1999 17:17:35 -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> OPINION: >> >> My personal preference is to take a non-persistent DEVFS. ...as it is mine as well. The main argument in favor of persistence is that operators may assume that doing a chmod/chown on files in /dev will be permanent. If this assumption is not correct, then it can lead to potential security holes that may go unnoticed to the inexperianced operator after the next reboot. The secondary argument is that non-persistence violates the Principle of Least Astonishment. Of course, this only applies to people who are new to FreeBSD, and I'd expect the more intelligent of the newbies to wonder how it works when they notice /dev show up in 'df' output. The first argument about security can be addressed by simply making all device nodes owned root/wheel, mode 0000 by default. This has the positive side-effect of not having to hard code policy in the driver sources. The secondary argument can be fixed with education and good documentation. Nonetheless, there are a fair number of people who feel religiously about this issue, so it will be a tough decision for some part of the usership to swallow, no matter what direction we go with devfs. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 17:34:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA20360 for freebsd-arch-outgoing; Fri, 1 Jan 1999 17:34:44 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA20343 for ; Fri, 1 Jan 1999 17:34:39 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id CAA02833 for ; Sat, 2 Jan 1999 02:34:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id CAA89787 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 02:34:16 +0100 (MET) Received: from dingo.cdrom.com (castles215.castles.com [208.214.165.215]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA18850 for ; Fri, 1 Jan 1999 17:19:15 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id RAA03885; Fri, 1 Jan 1999 17:16:10 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901020116.RAA03885@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Joerg Wunsch cc: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 01:04:59 +0100." <19990102010459.42125@uriah.heep.sax.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Jan 1999 17:16:09 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I don't particularly like the idea that you can thus destroy a device > access point accidentally. I'd like to see some method for the > sysadmin to tell the kernel to `go back and re-establish its idea of > the DEVFS'. My personal preference for this is for it to be handled by mknod. The mknod(2) syscall would un-whiteout a device node (or nodes), allowing you to bring them back from the dead (perhaps modulo securelevel). > If at all (readers might notice I'm not much a fanatic of persistence > here ;), then it should be an ASCII file somewhere. By no means, it > should be recorded in some unmanipulatable form. Personally, I think a persistent DEVFS would be "better" than a non-persistent DEVFS. But it's been quite clear for some time that persistence is something that can be built onto a working DEVFS, so a non-persistent DEVFS is something that we definitely want to start with. -- \\ 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 19:10:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA29590 for freebsd-arch-outgoing; Fri, 1 Jan 1999 19:10:36 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA29583 for ; Fri, 1 Jan 1999 19:10:34 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id EAA05042 for ; Sat, 2 Jan 1999 04:10:10 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA93465 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 04:10:09 +0100 (MET) Received: from dingo.cdrom.com (castles215.castles.com [208.214.165.215]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28899; Fri, 1 Jan 1999 18:59:02 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id SAA06431; Fri, 1 Jan 1999 18:54:50 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901020254.SAA06431@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Chuck Robey cc: Poul-Henning Kamp , arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 18:55:40 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Jan 1999 18:54:49 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Anyhow, moving to the lack of defaults ... you claim that there is no > method of restoring default values to a device, once that device has > been modified in the persistence database. There's no existing method, but plenty of room to overload the 'chmod' syscall semantics to indicate that a node should restore itself to its defaults. -- \\ 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 freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 19:17:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA00263 for freebsd-arch-outgoing; Fri, 1 Jan 1999 19:17:33 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA00250 for ; Fri, 1 Jan 1999 19:17:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id EAA05085 for ; Sat, 2 Jan 1999 04:17:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA93496 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 04:17:07 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA29882 for ; Fri, 1 Jan 1999 19:15:15 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zwHWS-0001IQ-00; Fri, 1 Jan 1999 20:14:40 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id UAA09044; Fri, 1 Jan 1999 20:12:52 -0700 (MST) Message-Id: <199901020312.UAA09044@harmony.village.org> To: Mike Smith Subject: Re: DEVFS, the time has come... Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 01 Jan 1999 17:16:09 PST." <199901020116.RAA03885@dingo.cdrom.com> References: <199901020116.RAA03885@dingo.cdrom.com> Date: Fri, 01 Jan 1999 20:12:52 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What we absolutely must not do is to create devices that will cause the security of the system to be compromised. This would be absolutely disasterous from a PR point of view. In message <199901020116.RAA03885@dingo.cdrom.com> Mike Smith writes: > Personally, I think a persistent DEVFS would be "better" than a > non-persistent DEVFS. But it's been quite clear for some time that > persistence is something that can be built onto a working DEVFS, so a > non-persistent DEVFS is something that we definitely want to start with. I think this is a good bottom line. Even if we had good documentation, I think it will still violate POLA. We must remember that rc.* is not an acceptible solution because devices can come and go. If my mouse were plugged into a USB port, and I unplugged it then plugged it back in, the device would go away and come back. If I chmod'd it on boot, those setting would be lost. Or if I forgot to have my mouse plugged in on boot and plugged it in after the rc scripts had run. The system still should allow access to that mouse, but only to the person that is on the console. We'd likely get lots of complaints if we violate POLA where removable devices are concerned. I know it is a huge PITA to do persistance correctly, and that people have fought doing it for years. However, I think that you need some level of persistance in order to deal with what will become an increasing common problem. Warner [The problem of insecure device-creations can be solved by defaulting to not create devices dynamically after boot. -EE] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 20:46:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA08430 for freebsd-arch-outgoing; Fri, 1 Jan 1999 20:46:58 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA08425 for ; Fri, 1 Jan 1999 20:46:56 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id FAA05627 for ; Sat, 2 Jan 1999 05:46:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA93714 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 05:46:31 +0100 (MET) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA07533 for ; Fri, 1 Jan 1999 20:39:21 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id VAA11728; Fri, 1 Jan 1999 21:38:51 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA15410; Fri, 1 Jan 1999 21:38:50 -0700 Date: Fri, 1 Jan 1999 21:38:50 -0700 Message-Id: <199901020438.VAA15410@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: Mike Smith , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-Reply-To: <199901020312.UAA09044@harmony.village.org> References: <199901020116.RAA03885@dingo.cdrom.com> <199901020312.UAA09044@harmony.village.org> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Personally, I think a persistent DEVFS would be "better" than a > > non-persistent DEVFS. But it's been quite clear for some time that > > persistence is something that can be built onto a working DEVFS, so a > > non-persistent DEVFS is something that we definitely want to start with. > > We must remember that rc.* is not an acceptible solution because > devices can come and go. Agreed, this is my point exactly. To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to say that my experience with Solaris has been less than enthusiastic. Note, it only dealt with one device (the tape drive), but it was a pain in the butt. I setup the machine so that 'normal users' could do their own backups to the tape drive, but the default permissions would not allow this to work, so I had to 'chmod' the device special node. The combination of the Solaris init implementation (where do I stick the chmod call in the mess of init files?), the fact that the tape drive was 'mobile' (it moved to a PC for backups on occasion), and the fact that I couldn't make the mods persistent w/out a lot of work. Yes, it could be done, but it was a huge pain in the backside to get it to work 100%, and it shouldn't be that much work IMO. > If my mouse were plugged into a USB port, > and I unplugged it then plugged it back in, the device would go away > and come back. If I chmod'd it on boot, those setting would be lost. I hope this isn't lost in the noise. Any 'boot' configuration is a loss for the (hopefully soon to be coming) 'dynamic' scheme that keeps getting talked about. Devices will come and go, and any scheme that doesn't take this into account will be a net loss. Also, if it requires too much user intervention to mess with things it will also be a net loss. Ex: I want to add a modem card to my FreeBSD laptop system. 1) Edit /etc/pccard.conf and add the new devices. 2) Edit /etc/devfs.init to add the new serial devices permissions. 3) Kill -hup /var/run/devfs.pid 4) Insert the card, and hope you got everything right. You get the point. If we plan on making the system secure out of the box, then we need a way for people to make it usable w/out too much grief. > [The problem of insecure device-creations can be solved by defaulting > to not create devices dynamically after boot. -EE] This is unacceptable with hardware such as laptops and such. We are trying to move to a more dynamic model for the kernel, and this flies completely in the face of this. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Jan 1 21:10:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA09826 for freebsd-arch-outgoing; Fri, 1 Jan 1999 21:10:07 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA09811 for ; Fri, 1 Jan 1999 21:10:05 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id GAA05771 for ; Sat, 2 Jan 1999 06:09:42 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA93787 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 06:09:41 +0100 (MET) Received: from dingo.cdrom.com (castles354.castles.com [208.214.167.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA09247 for ; Fri, 1 Jan 1999 20:59:23 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id UAA01211; Fri, 1 Jan 1999 20:55:56 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901020455.UAA01211@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Nate Williams cc: Warner Losh , Mike Smith , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 21:38:50 MST." <199901020438.VAA15410@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Jan 1999 20:55:55 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to > say that my experience with Solaris has been less than enthusiastic. > Note, it only dealt with one device (the tape drive), but it was a pain > in the butt. > > I setup the machine so that 'normal users' could do their own backups to > the tape drive, but the default permissions would not allow this to > work, so I had to 'chmod' the device special node. The combination of > the Solaris init implementation (where do I stick the chmod call in the > mess of init files?), the fact that the tape drive was 'mobile' (it > moved to a PC for backups on occasion), and the fact that I couldn't > make the mods persistent w/out a lot of work. > > Yes, it could be done, but it was a huge pain in the backside to get it > to work 100%, and it shouldn't be that much work IMO. This sounds more like you were bitten by the lack of easily-adapted support infrastructure than that the basic concept is flawed, especially as the case you offer as support is one that would be a non-issue with our infrastructure. > > If my mouse were plugged into a USB port, > > and I unplugged it then plugged it back in, the device would go away > > and come back. If I chmod'd it on boot, those setting would be lost. > > I hope this isn't lost in the noise. Any 'boot' configuration is a loss > for the (hopefully soon to be coming) 'dynamic' scheme that keeps > getting talked about. Devices will come and go, and any scheme that > doesn't take this into account will be a net loss. I was just discussing this with Eivind; I think that we can comfortably cover every set of requirements with: - a kernel-wide default owner/group/permissions for new nodes, which can be overridden by the device driver in response to eg. configuration arguments or device-specific concerns. - a mount option which determines whether new nodes show up in the devfs instance. > You get the point. If we plan on making the system secure out of the > box, then we need a way for people to make it usable w/out too much > grief. This is a key point, yes. -- \\ 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 freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 09:17:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04223 for freebsd-arch-outgoing; Sat, 2 Jan 1999 09:17:34 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA04218 for ; Sat, 2 Jan 1999 09:17:32 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id SAA23676 for ; Sat, 2 Jan 1999 18:17:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA95276 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 18:17:05 +0100 (MET) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA09958 for ; Fri, 1 Jan 1999 21:12:03 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA11937; Fri, 1 Jan 1999 22:11:36 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA15502; Fri, 1 Jan 1999 22:11:36 -0700 Date: Fri, 1 Jan 1999 22:11:36 -0700 Message-Id: <199901020511.WAA15502@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-To: Mike Smith X-Cc: Nate Williams , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-Reply-To: <199901020455.UAA01211@dingo.cdrom.com> References: <199901020438.VAA15410@mt.sri.com> <199901020455.UAA01211@dingo.cdrom.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid To: undisclosed-recipients:; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to > > say that my experience with Solaris has been less than enthusiastic. > > Note, it only dealt with one device (the tape drive), but it was a pain > > in the butt. > > > > I setup the machine so that 'normal users' could do their own backups to > > the tape drive, but the default permissions would not allow this to > > work, so I had to 'chmod' the device special node. The combination of > > the Solaris init implementation (where do I stick the chmod call in the > > mess of init files?), the fact that the tape drive was 'mobile' (it > > moved to a PC for backups on occasion), and the fact that I couldn't > > make the mods persistent w/out a lot of work. > > > > Yes, it could be done, but it was a huge pain in the backside to get it > > to work 100%, and it shouldn't be that much work IMO. > > This sounds more like you were bitten by the lack of easily-adapted > support infrastructure than that the basic concept is flawed, > especially as the case you offer as support is one that would be a > non-issue with our infrastructure. What infrastructure? Nothing exists at this point in FreeBSD to do this 'easily'. There is lots of hand-waving, but nobody has even agreed on *what* form a persistence mechanism would take, other than those who argue 'we really don't need it'. :( We've got boot rc.* scripts (which I hope Warner has pointed out is insufficient), and the infamous 'daemon', which IMO would be difficult to customize easily, and then Mike's 'white-out FS' design, which sounds good on paper and is similiar in scope to what was dicussed a long time ago with some sort of 'union mount' over top of DEVFS. I'd like to see something of substance *implemented* before we agree to go with DEVFS. There are still also outstanding issues of *how* a device node shows up in the first place. We still have the chicken/egg problems of whether or not to create device nodes for *every* conceivable disk device for a particular disk (wd0, wd0a, wd0s1a, wd0s2a, etc...), which SLICE was supposed to help with. This issue is somewhat orthogonal to persistence, but in some ways could make things easier, in that once it was determined *which* devices were needed the rest could be 'cleaned' out of the /dev directory. Of course, we'd still need a way to 're-surrect' some of the nodes if the configuration changed. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 09:23:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA04830 for freebsd-arch-outgoing; Sat, 2 Jan 1999 09:23:54 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA04824 for ; Sat, 2 Jan 1999 09:23:51 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id SAA23750 for ; Sat, 2 Jan 1999 18:23:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA95316 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 18:23:26 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA10380 for ; Fri, 1 Jan 1999 21:14:40 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zwJO6-0001KU-00; Fri, 1 Jan 1999 22:14:10 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id WAA09287 for ; Fri, 1 Jan 1999 22:12:23 -0700 (MST) Message-Id: <199901020512.WAA09287@harmony.village.org> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 20:55:55 PST." <199901020455.UAA01211@dingo.cdrom.com> References: <199901020455.UAA01211@dingo.cdrom.com> Date: Fri, 01 Jan 1999 22:12:23 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901020455.UAA01211@dingo.cdrom.com> Mike Smith writes: > I was just discussing this with Eivind; I think that we can comfortably > cover every set of requirements with: > > - a kernel-wide default owner/group/permissions for new nodes, which > can be overridden by the device driver in response to eg. > configuration arguments or device-specific concerns. This may work OK, but there needs to be some way to have an effective infrastructure to allow this to be changed when the devices come and go. It still doesn't answer the problems that I wrote about in earlier messages. Namely if I chown imp /dev/mouse, and then i unplug the mouse and plug it back in, what should happen? Should it revert to root ownership? Or should it revert to imp ownership. I think the latter. What permissions should be retained? This is a thorny issue that we cannot afford to punt on in the long term. We need to have mechanisms in place for dealing with exactly this sort of thing. EE says: > [My only concern with a non-persistent DEVFS is the permissions on > device nodes that appear due to an event (e.g, a card insertion), and > I think the can be adequately addressed by having a flag for a DEVFS > mount that stop new nodes from automatically appearing in that > instance of DEVFS. -EE] EE also says: > [The problem of insecure device-creations can be solved by defaulting > to not create devices dynamically after boot. -EE] I don't think that solves any problems. You just make devices useless then. If I had forgotten to plug my USB mouse in on boot, I shouldn't have to reboot to get it. Also, if I unplug my mouse after it has been chown'd to me, and then plug it back in, I should still own the mouse. In a static world the rc.dev script is an excellent solution, but with devices coming and going over time a better solution is needed. While the static solution would be better than no solution at all, there needs to be some thought as to what the long term solutions to this problem is going to be as things get more and more dynamic. Disallowing dynamic creation of device nodes in a devfs mounted system seems counterproductive to me. I'd go farther and say that I don't think that a devfs option to disable new nodes appearing is even acceptable. It must not be required to have a secure system. When the kernel boots, any card devices are not detected. It is only after pccardd starts that they are detected and configured in the kernel. This could introduce a race condition (did the dev script run before or after this device was added). pccardd doesn't even guarantee when it will get around to dealing with cards in the PCMCIA bus when the system boots. It is started way late in the game. Much later than any rc.dev script would run. Also, with CAM new devices can come and go at any time. I can rescan the SCSI bus and have the scanner or tape or whatever I forgot to turn on at boot time come to life, or that I plugged into the SCSI bus after boot for the purposes of gaming or backups. There needs to be some standard, sane way of dealing with these issues and a plan for them over the long haul. While the next iteration of DEVFS need not address these issues, they will need to be addressed before DEVFS can become default, especially the security ones. The biggest problem with the current incarnation of devfs is its inability to deal with devices being added from interrupt context. Once that is solved, we'd have a good version 0 of devfs. Until a mechanism can be put into place for dealing with these thorny issues, making it default (aka version 1) will need to wait. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:14:18 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA09269 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:14:18 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA09264 for ; Sat, 2 Jan 1999 10:14:15 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24144 for ; Sat, 2 Jan 1999 19:13:51 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95486 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:13:50 +0100 (MET) Received: from dingo.cdrom.com (castles354.castles.com [208.214.167.54]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA11035 for ; Fri, 1 Jan 1999 21:21:33 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (LOCALHOST [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id VAA00463; Fri, 1 Jan 1999 21:18:09 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901020518.VAA00463@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 X-To: Nate Williams X-cc: Mike Smith , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 22:11:36 MST." <199901020511.WAA15502@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 01 Jan 1999 21:18:08 -0800 From: Mike Smith To: undisclosed-recipients:; Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to > > > say that my experience with Solaris has been less than enthusiastic. > > > Note, it only dealt with one device (the tape drive), but it was a pain > > > in the butt. > > > > > > I setup the machine so that 'normal users' could do their own backups to > > > the tape drive, but the default permissions would not allow this to > > > work, so I had to 'chmod' the device special node. The combination of > > > the Solaris init implementation (where do I stick the chmod call in the > > > mess of init files?), the fact that the tape drive was 'mobile' (it > > > moved to a PC for backups on occasion), and the fact that I couldn't > > > make the mods persistent w/out a lot of work. > > > > > > Yes, it could be done, but it was a huge pain in the backside to get it > > > to work 100%, and it shouldn't be that much work IMO. > > > > This sounds more like you were bitten by the lack of easily-adapted > > support infrastructure than that the basic concept is flawed, > > especially as the case you offer as support is one that would be a > > non-issue with our infrastructure. > > What infrastructure? Nothing exists at this point in FreeBSD to do this > 'easily'. There is lots of hand-waving, but nobody has even agreed on > *what* form a persistence mechanism would take, other than those who > argue 'we really don't need it'. :( You were specifically complaining about not being able to fix something that a boot-time script would have been more than adequate for. > We've got boot rc.* scripts (which I hope Warner has pointed out is > insufficient), Actually, in most cases they'd be fine, if decidedly inelegant. > and the infamous 'daemon', which IMO would be difficult > to customize easily, A non-comment on a non-design. > I'd like to see something of substance *implemented* before we agree to > go with DEVFS. How can you implement something for something else that doesn't exist? > There are still also outstanding issues of *how* a device node shows up > in the first place. We still have the chicken/egg problems of whether > or not to create device nodes for *every* conceivable disk device for a > particular disk (wd0, wd0a, wd0s1a, wd0s2a, etc...), which SLICE was > supposed to help with. Lack of SLICE-equivalent functionality would instantly disqualify any DEVFS candidate; I think that much has to be obvious. -- \\ 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 freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:20:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10251 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:20:09 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA10208 for ; Sat, 2 Jan 1999 10:20:04 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24198 for ; Sat, 2 Jan 1999 19:19:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95517 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:19:33 +0100 (MET) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA16398 for ; Fri, 1 Jan 1999 22:39:53 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (peter@localhost [127.0.0.1]) by spinner.netplex.com.au (8.9.1/8.9.1/Netplex) with ESMTP id OAA03578; Sat, 2 Jan 1999 14:35:12 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199901020635.OAA03578@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-arch@FreeBSD.ORG X-To: Mike Smith X-cc: Nate Williams , Warner Losh , freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 20:55:55 PST." <199901020455.UAA01211@dingo.cdrom.com> Date: Sat, 02 Jan 1999 14:35:03 +0800 Mail-Followup-To: freebsd-arch@freebsd.org From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Mike Smith wrote: [..] > > > If my mouse were plugged into a USB port, > > > and I unplugged it then plugged it back in, the device would go away > > > and come back. If I chmod'd it on boot, those setting would be lost. > > > > I hope this isn't lost in the noise. Any 'boot' configuration is a loss > > for the (hopefully soon to be coming) 'dynamic' scheme that keeps > > getting talked about. Devices will come and go, and any scheme that > > doesn't take this into account will be a net loss. > > I was just discussing this with Eivind; I think that we can comfortably > cover every set of requirements with: > > - a kernel-wide default owner/group/permissions for new nodes, which > can be overridden by the device driver in response to eg. > configuration arguments or device-specific concerns. > - a mount option which determines whether new nodes show up in the > devfs instance. The way I imagine this would work (in a non-persistant devfs), would be that there would be some predefined device node permission classes that would set the default for devices of that type where there is likely to be changes in bulk depending on the role of the machine. For example, there might be a node for tty, pty, callout (modem) devices, tape, disk, sound, mouse (non-tty), and a default (0700, root, wheel). When a "new" device appears (including at boot), it would bind itself to the appropriate class, if it was appropriate. The key thing would be that the node would shadow the permissions of the class node until it was given explicit permissions of it's own. Suppose the class nodes were visible in sysctl. If somebody did this: sysctl -w vfs.devfs.class.tape.mode=0666 Then all the nodes that were attached would simultaniously change from the original (presumably 0600) to 0666. However, if /dev/rsa0 had previously been chmodded to 0660, it would have left the class and would not be affected by this change. This could cover problems like 'which uid is uucp'? At boot time, the rc scripts could set the vfs.devfs.class..uid=66 and the devfs would take shape. The advantage of this is that uids do not need to be encoded in the kernel, and it's relatively simple to tighten up or relax permissions on a large scale without having to resort to chmod/chown etc. This could be implemented by each node's control struct having a uid/gid/ mode field, and a pointer to a default node. If the default pointer was set, the local uid/gid/mode would be ignored, and VOP_GETATTR/VOP_ACCESS etc would pick up the permissions from the parent. This means that changing the sysctl wouldn't mean that devfs would have to sweep the node tree at all, since the permissions are looked up at access time. Device drivers only then would need minimal (or no) permission information. When attaching to the devfs, it may choose to nominate that "this is a pty" and the devfs will connect it under the pty default modes. If the driver doesn't specify at all, then it's a "default". Other nice things could be done would be magic self resetting permissions on last close (based on class), secure pty allocation and handoff (When the cloning pty master is opened, the slave appears with the same uid as the opener, mode 620, gid tty, all ready for the client to grab), etc. Re loosing nodes... Would 'mount -u -o reload /dev' cut it? Re chroot jails.. Would mounting an instance, cleaning it out and then doing a 'mount -u -r /my/chroot/jail/dev' cut it? (making it readonly would prevent changes, devices appearing, etc.) Yes, we need a devfs. Yes, it should be on by default. I prefer non-persistance, especially if measures are taken to make it easier to cope with. I would prefer to not have to put policy into drivers, but some will be unavoidable - /dev/null for example. Perhaps classifying nodes and having a group of settings might do the trick. Cheers, -Peter -- Peter Wemm Netplex Consulting "No coffee, No workee!" :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:22:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA10558 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:22:21 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA10540 for ; Sat, 2 Jan 1999 10:22:18 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24222 for ; Sat, 2 Jan 1999 19:21:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95540 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:21:53 +0100 (MET) 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 AAA23722 for ; Sat, 2 Jan 1999 00:05:43 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id BAA19906; Sat, 2 Jan 1999 01:05:17 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901020805.BAA19906@pluto.plutotech.com> X-To: Joerg Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 01:04:59 +0100." <19990102010459.42125@uriah.heep.sax.de> Date: Sat, 02 Jan 1999 00:57:32 -0700 Mail-Followup-To: freebsd-arch@FreeBSD.org From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > One of the major proponents of a persistent DEVFS was Justin, last > time we've been talking about it. It seems Justin's opinion is now > also to put all this out to userland, into something like a devfsd. I've always felt that much of the machinery of a persistent DEVFS should reside in userland, but that we'd be hard pressed to properly support a dynamic and secure system without persistence. My picture of a devfsd is a daemon with some text based configuration file allowing you to specify dynamic policy (Set the permisions on sa* to root:backup, 0600) as well as record the results of explicit chmod, chown, ln, mv, etc. operations on any DEVFS instance. It would do this via a new 'file modified' poll event type being monitored on all directories of DEVFS instances. There has been talk in the past of adding this kind of poll event for other reasons, but it would be perfect for this application. With this kind of approach, we are free to experiment with different persitence schemes without the underlying DEVFS having to worry about persistence at all. Of course, we need to discuss all of the different mount options that would be needed for chroot type instances and enhanced security (all nodes arrive in the whiteout state by default so they cannot be ls'd, global default permissions, etc). > One disadvantage of a devfsd is that it needs to remain in-core all > the time, or danger of deadlocks could arise. (IMHO) I don't why this would be an issue. Usually these kinds of things crop up in scenarios like halting the SCSI bus without a timeout period from a userland process that mightbe partially swapped out. The kernel should always retain access to configured swap partitions regardless of the activities of devfsd. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:30:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA11479 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:30:05 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA11399 for ; Sat, 2 Jan 1999 10:30:01 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24294 for ; Sat, 2 Jan 1999 19:29:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95555 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:29:36 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA03921 for ; Sat, 2 Jan 1999 02:42:01 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id LAA06042; Sat, 2 Jan 1999 11:36:46 +0100 (CET) To: Chuck Robey cc: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 18:55:40 EST." Date: Sat, 02 Jan 1999 11:36:45 +0100 Message-ID: <6040.915273405@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've gathered all my replies into this email to try to keep the focus. > From: Chuck Robey > > First, Poul, will you agree that the opinion of the great majority of > developers want persistence? No, I will not. I think the great majority of developers hasn't even thought about the pro-et-contra of the situation, or as the emails here convinced me, mixes the issue up with other more technical issues which have solutions in both cases. > To take it one step further, wasn't one of the main reasons for the > non-acceptance of our last devfs (not the only reason, but a main > reason) it's lack of a strategy for implementing persistence? There were more reasons than that, but please leave that out of the current discussion, that is not the subject we're trying to settle. > As such, default values could very easily be handled, couldn't they, > in a number of different ways, in fact. It could be done in ASCII > files (RO files, not modifiable), or the drivers themselves could > store such stuff, and regurgitate it on ioctl calls, right? It > could even be done via sysctl, although that strikes me as a bit > weird. If you look at your suggestion, will you not agree with me that this sounds like a bunch of gross hacks which would violate POLA big time ? > From: J Wunsch > >> NON-PERSISTENT DEVFS: > > I don't see any form of an implementation for `whiteout' and > `undelete' so far. > > Well, one question sideways: does this mean all the problems with > disks entered after boot-time have been resolved in the existing > implementation? Please disregard the current implementation and its limitations and focus on the hot spot of this discussion. >> How about the case where people try out some gadget, forgets about >> it for a number of months and buy some other gadget instead which >> the same driver recognizes, then suddenly some old stuff appears >> out of nowhere which may not even apply to that device, and since >> the device is there in the database, not even the device driver >> gets a chance to say what it feels about the issue ? > > In AIX, it would have become instance #1 for the new gadget, with > keeping the old instance #0 in mind for eternity. :-) Unless of course you put it in the same slot :-( Yes, I think AIX did as good a job on persistence as you can do, modulus a few representation issues, and that is one of the reasons why I don't want persistence. The fact that the IBM subsidiary who made the ATM adapter for the RS/6K didn't register their hardware at all and when told so said "Sorry that scheme sucks and we're not going to burn our users with it" certainly made an impression on me. > From: Mike Smith > >> I don't particularly like the idea that you can thus destroy a device >> access point accidentally. I'd like to see some method for the >> sysadmin to tell the kernel to `go back and re-establish its idea of >> the DEVFS'. > > My personal preference for this is for it to be handled by mknod. The > mknod(2) syscall would un-whiteout a device node (or nodes), allowing > you to bring them back from the dead (perhaps modulo securelevel). But if you think about chroot for a moment, it will be obvious to you that we need a way to hide (whiteout) and to destroy for good (unlink) a node. You would not want it to be possible to bring them back in a chroot jail. Agreed, that could also be handled by the same mount option which says "show me no new devices". Lets bag this point as an implementation issue. It is not material to the persistence/non-persistence debate. > From: Warner Losh > > What we absolutely must not do is to create devices that will cause > the security of the system to be compromised. This would be > absolutely disasterous from a PR point of view. Agreed. This is where I think a persistent DEVFS has a big problem because old stuff will be kept around. We have no way of knowing if a particular device is gone for good or will come back. And we have no way to know, if it comes back, if the users considers it the same device in the first place. > In message <199901020116.RAA03885@dingo.cdrom.com> Mike Smith writes: > > Even if we had good documentation, I think it will still violate POLA. I think /dev in its current form is a violation of POLA, at least when you accidentially create a large file called /dev/rsy0... > We must remember that rc.* is not an acceptible solution because > devices can come and go. Devices which come and go will need a daemon anyway to swing them into action (mount, ifconfig and so on). I have deliberately kept this daemon out of the picture, because it raises another bunch of sensitive issues and it does not depend on the persistence or not of the underlying DEVFS. I have detailed a little bit about it at the end of this email, but please lets try to stay focused in this discussion. >From a security point of view, the new devices will come up 000/root/wheel in a non-persistent DEVFS, and whatever happens to be in the persistence database in a persistent DEVFS. > From: Warner Losh > > In another message I went over some of my security concerns, others > have raised them as well. Basically, I don't want to see anything > which would lessen the security of the system. This is an important point also for me, and it is where I am very afraid of this dormant stuff in the persistence database. > From: Nate Williams > > To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to > say that my experience with Solaris has been less than enthusiastic. > Note, it only dealt with one device (the tape drive), but it was a pain > in the butt. I think there is widespread agreement that Solaris got it about as wrong as they could. ------------------- I would like to ask you all to refocus on the POLA part of the discussion here, since all the other stuff you have raised all have technical (if in some cases cumbersome) solutions for both kinds of DEVFS. Obviously if we implement the daemon-assisted approach right away, we could make it a switch if we wanted persistence, but I think that would be asking for trouble BIG time. Then some systems would have it and others not, and 3rd party developers would be screwed badly. The question remains more or less: Do we want a "chmod 764 /dev/foo" to be persistent over reboot, despite the significant amount of code it takes, and the potential to pop out of the blue six months later and bite people ? So far I hear the following clear opinion: Joerg: non-persistent DavidG: non-persistent Poul-Henning: non-persistent I think I hear Mike Smith saying: "I want persistence for persistence sake" And I hear a number of people who don't really care that much, as long as a number of concerns are addressed (although some seem to think that persistence will be better able to address these issues). Correct me if I'm wrong. ------------------------------------------------------------------------------ Let me fill on some background stuff on the daemon. A dynamic device daemon ("devd"), can of course also handle the static devices, they're no different, they're just not as dynamic. The simplest daemon will spot a change in the /dev tree, and go look for a command: /etc/dev.d/$devicename$unit failing that it will look for: /etc/dev.d/$devicename failing that it will look for: /etc/dev.d/default having found it it will: $command {come|go} $devicename $unit So our /etc/dev.rc has become /etc/dev.d/default and contains a big switch (sounds like MAKEDEV, doesn't it ?) The applicable command can and should obviously set the mode/owner/group of the /dev nodes along with other stuff (ifconfig/mount...) it might do. Now, problems: Imagine a ZIP drive. Plugging it in is easy, and it gets mounted and used. Now I unplug it. The device node cannot disappear until it has been unmounted (last close) obviously, so the device driver will have to send a signal to the devd process saying "I'm toast", so that devd can umount (-force) which will make the device node disappear (on last close). So the "go away" event is NOT triggered by the disappearance of the device node in /dev, that complicates matters a bit. This could be handled by a call from the device driver to the DEVFS informing of the wish to disappear once cleanup is done. Obviously a non-open device can just pack up and leave. As I said above, this doesn't really have any thing to do with the persistence or not issue, so just consider this background info, and lets not start a debate about this stuff yet. You will get your chance on this stuff later on, don't worry :-) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:33:32 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA11763 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:33:32 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA11754 for ; Sat, 2 Jan 1999 10:33:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24327 for ; Sat, 2 Jan 1999 19:33:06 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95595 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:33:06 +0100 (MET) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA08966 for ; Sat, 2 Jan 1999 03:50:51 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id MAA20368 for freebsd-arch@FreeBSD.ORG; Sat, 2 Jan 1999 12:50:27 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id MAA13309; Sat, 2 Jan 1999 12:41:13 +0100 (MET) (envelope-from j) Message-ID: <19990102124112.29898@uriah.heep.sax.de> Date: Sat, 2 Jan 1999 12:41:12 +0100 From: J Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Reply-To: Joerg Wunsch References: <199901020116.RAA03885@dingo.cdrom.com> <199901020312.UAA09044@harmony.village.org> <199901020438.VAA15410@mt.sri.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199901020438.VAA15410@mt.sri.com>; from Nate Williams on Fri, Jan 01, 1999 at 09:38:50PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Nate Williams wrote: > To counter Joerg's 'not bothered by non-persistent DEVFS', I'd have to > say that my experience with Solaris has been less than enthusiastic. > Note, it only dealt with one device (the tape drive), but it was a pain > in the butt. Well, that's funny. It's not funny that you had problems with Solaris, but it's funny since in some recent discussion in -core, I quoted Solaris as an example of a persistent DEVFS that has been causing me major grief _due to its persistence_. (Jordan's reply was that the grief is mainly caused by a poor implementation, not by the fact that they've implemented persistence. He's probably right on this.) I can't follow you on this, btw, and have just tried it again. The Solaris implementation _is_ persistent, and they store their persistent data in the root f/s (which I believe is terribly wrong). I have been able to chmod something, and to reboot, and everything was as previously. Their persistence is sticky until you boot -r (or run drvconfig(1m), and even then, old devices under /devices and /dev are remembered forever unless you manually rm the entries there (sounds like AIX, doesn't it? :). I always found this terrible, since there's no clean way to tell the system to ``go to hell and restart from scratch''. My bad experience with them was an attempt to migrate a disk from an Ultra 10 machine with a SymBios Logic SCSI card to a Sun AXi OEM-board based clone with an onboard SymBios Logic. Although both architectures are fairly similar, it has proven to be plain impossible to do this, short of a reboot from a CD-ROM after the migration, mounting the disk's root f/s, rm -rf'ing all the /dev and /devices cruft, and copying it over from the dynamically created /dev and /devices that exist in the CD-ROM environment. This is a good example of something I'd never like to happen to a FreeBSD disk. But again, that's probably more a point to prove that the Solaris _implementation_ is poor, not that persistence itself is something that sucks. But maybe then, it could be that any possible implementation of a persistent DEVFS sucks similarly. :.) (After working with some really large server machine, I began to understand why they did some things the way they did, still I believe it could have been done better.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:40:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA12751 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:40:55 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA12746 for ; Sat, 2 Jan 1999 10:40:53 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24393 for ; Sat, 2 Jan 1999 19:40:29 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95637 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:40:29 +0100 (MET) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA13445 for ; Sat, 2 Jan 1999 04:20:47 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id NAA20676 for freebsd-arch@FreeBSD.ORG; Sat, 2 Jan 1999 13:20:24 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id NAA13478; Sat, 2 Jan 1999 13:03:16 +0100 (MET) (envelope-from j) Message-ID: <19990102130314.49604@uriah.heep.sax.de> Date: Sat, 2 Jan 1999 13:03:14 +0100 From: J Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Reply-To: Joerg Wunsch References: <19990102010459.42125@uriah.heep.sax.de> <199901020805.BAA19906@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199901020805.BAA19906@pluto.plutotech.com>; from Justin T. Gibbs on Sat, Jan 02, 1999 at 12:57:32AM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Justin T. Gibbs wrote: > My picture of a devfsd is a daemon with some text based configuration > file allowing you to specify dynamic policy (Set the permisions on > sa* to root:backup, 0600) as well as record the results of explicit > chmod, chown, ln, mv, etc. operations on any DEVFS instance. I feel I could live with _that_ way of persistence rather well. It would also allow for both implementations to compete (a persistent one via a devfsd, and a hand-edited policy description via rc.devfs) for some time, in order to see which one might be the best. Regardless of which one we choose, the kernelland is about the same and any required details about the kernel part of DEVFS could be clarified quickly, so necessary actions (like possibly revamping the entire kernel implementation should this be required) won't be deferred again for a long period. I take it from all the people who raised their voice so far that all are in happy agreement that DEVFS should become the future standard (and since it has been deferred for too long already, this should be done in something like 3.1-RELEASE)? This was one of Poul-Henning's questions, too. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:47:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13304 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:47:58 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13299 for ; Sat, 2 Jan 1999 10:47:55 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24450 for ; Sat, 2 Jan 1999 19:47:31 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95671 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:47:30 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA19695 for ; Fri, 1 Jan 1999 23:15:40 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zwLHD-0001Mv-00; Sat, 2 Jan 1999 00:15:11 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id AAA09699; Sat, 2 Jan 1999 00:13:25 -0700 (MST) Message-Id: <199901020713.AAA09699@harmony.village.org> X-To: Peter Wemm Subject: Re: DEVFS, the time has come... To: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Sat, 02 Jan 1999 14:35:03 +0800." <199901020635.OAA03578@spinner.netplex.com.au> References: <199901020635.OAA03578@spinner.netplex.com.au> Date: Sat, 02 Jan 1999 00:13:24 -0700 Mail-Followup-To: freebsd-arch@FreeBSD.org From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901020635.OAA03578@spinner.netplex.com.au> Peter Wemm writes: [trimmed, an excellent recap of the past discussions] > Re chroot jails.. Would mounting an instance, cleaning it out and then > doing a 'mount -u -r /my/chroot/jail/dev' cut it? (making it readonly > would prevent changes, devices appearing, etc.) I withdraw my objection to having devfs add/remove devices from some file systems. I didn't even think about chroot jails. Accessing devices in chroot jails is useful enough for an interesting number of cases to allow that. > Yes, we need a devfs. Yes, it should be on by default. I prefer > non-persistance, especially if measures are taken to make it easier to > cope with. I would prefer to not have to put policy into drivers, but > some will be unavoidable - /dev/null for example. Perhaps classifying > nodes and having a group of settings might do the trick. I agree with this sentiment. I also agree that we need devfs more than we need to have persistance. So long as there is a way to change the default settings of a class on the fly, then this will work for the examples I've been giving: new pccard device as well as a mouse appear/disappear. If I wanted to grant ownership to the console devices to one person, I'd just set the defaults to that person. Then it doesn't matter. While rough around the edges, I think what Peter has outlined will be better enough to move forward w/o persistance. Any discussion of this in the larger context needs to have something that is that clear and shows that most cases are covered well enough and leave the rest for devfs v2 if the well enough devolves over time and needs fixing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 10:53:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA13795 for freebsd-arch-outgoing; Sat, 2 Jan 1999 10:53:04 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13790 for ; Sat, 2 Jan 1999 10:53:02 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24501 for ; Sat, 2 Jan 1999 19:52:38 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95710 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:52:38 +0100 (MET) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA13287 for ; Sat, 2 Jan 1999 10:47:48 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.1/8.8.5) with ESMTP id TAA07046; Sat, 2 Jan 1999 19:46:07 +0100 (CET) To: "Justin T. Gibbs" cc: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 00:57:32 MST." <199901020805.BAA19906@pluto.plutotech.com> Date: Sat, 02 Jan 1999 19:46:06 +0100 Message-ID: <7044.915302766@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901020805.BAA19906@pluto.plutotech.com>, "Justin T. Gibbs" writes: >> One of the major proponents of a persistent DEVFS was Justin, last >> time we've been talking about it. It seems Justin's opinion is now >> also to put all this out to userland, into something like a devfsd. > > I've always felt that much of the machinery of a persistent DEVFS > should reside in userland, but that we'd be hard pressed to properly > support a dynamic and secure system without persistence. Justin, would you mind clairfying that last concern ? (This is what this thread is about, not about implementation details, which there are NO reason to haggle about at this time, so please stop wasting our time. This is about persistence or non-persistence, not about how chroot /devs get mounted or with which options.) [I feel that it is difficult to get a 'handle' on which problems there are with persistence or lack thereof without having reasonably clear ideas of how it will be implemented, so I'm letting some messages on this through. However, try to keep your comments closely related to the issue of whether persistence in and of itself is required. -EE] -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." "ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 2 11:00:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15117 for freebsd-arch-outgoing; Sat, 2 Jan 1999 11:00:09 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15107 for ; Sat, 2 Jan 1999 11:00:07 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id TAA24583 for ; Sat, 2 Jan 1999 19:59:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA95798 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 19:59:43 +0100 (MET) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA08975 for ; Sat, 2 Jan 1999 03:50:54 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id MAA20371 for freebsd-arch@FreeBSD.ORG; Sat, 2 Jan 1999 12:50:31 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.9.1/8.9.1) id MAA13318; Sat, 2 Jan 1999 12:43:31 +0100 (MET) (envelope-from j) Message-ID: <19990102124331.02468@uriah.heep.sax.de> Date: Sat, 2 Jan 1999 12:43:31 +0100 From: J Wunsch To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Reply-To: Joerg Wunsch References: <199901020438.VAA15410@mt.sri.com> <199901020455.UAA01211@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199901020455.UAA01211@dingo.cdrom.com>; from Mike Smith on Fri, Jan 01, 1999 at 08:55:55PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Mike Smith wrote: > I was just discussing this with Eivind; I think that we can comfortably > cover every set of requirements with: > > - a kernel-wide default owner/group/permissions for new nodes, which > can be overridden by the device driver in response to eg. > configuration arguments or device-specific concerns. I think (and I know i'm not alone with this) that the kernel should have no further knowledge of UIDs and GIDs except UID/GID 0:0. Everything else violates the POLA in case someone edits her /etc/master.passwd and /etc/group (and I hope you don't suggest that the kernel might read those files ;-) [This is slightly on the side of the present discussion, but can serve as relevant background for those thinking of persistence. I'm unlikely to approve any follow-ups on this message. -EE] -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message