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