From owner-freebsd-arch Sun Jan 3 09:16:01 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA14519 for freebsd-arch-outgoing; Sun, 3 Jan 1999 09:13: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 JAA14505 for ; Sun, 3 Jan 1999 09:13:54 -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 SAA16855 for ; Sun, 3 Jan 1999 18:13:28 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA98961 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 18:13:27 +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 SAA04455 for ; Sat, 2 Jan 1999 18:58:17 -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 TAA05638; Sat, 2 Jan 1999 19:54:41 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901030254.TAA05638@pluto.plutotech.com> X-To: Poul-Henning Kamp To: arch@freebsd.org Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 11:36:45 +0100." <6040.915273405@critter.freebsd.dk> Date: Sat, 02 Jan 1999 19:46:56 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@freebsd.org Precedence: bulk X-Loop: FreeBSD.ORG > 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. Actually it partially speaks to the persistence issue. Somewhere there is persistent data specifying that certain DEVFS instances have certain attributes. In other words, you haven't properly defined what persistent attributes are allowed in a 'non-persistent DEVFS' and what is not. >> 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. You have the same problem if they decide to edit rc.devs and forget about it. You seem to have already acknowledged that the administrator must be able to control the policy of device permissions, and now we're just down to how that is achieved persistently (scripts, or daemon, or something else?). >> 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). Which means having several programs read different configuration files detailing persistent attributes for device node permissions? I'd much rather push all such policy into one place than have to guess which of many potential culprits have munged my dev nodes. It also centralizes policy so that it can be easily audited. > 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. The underlying DEVFS does not need to be persistent. >> 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. You cannot avoid this issue as persistence of some sort needs to be maintained somewhere. My solution to this is to centralize the policy so that it can be easily maintained and reviewed. >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. Then perhaps we should refocus the discussion on the types of administrative policies for device nodes that we must allow. Once that is determined, our hand will be forced into a particular type of persistence implementation. My vote on this is that the administrator should be able to: 1) Rename/symlink device nodes (/dev/pass4 hardwired to the location of the systems scanner becomes /dev/scanner0, etc.) 2) Change the permissions and owner of arbitrary device nodes or classes of device nodes (/dev/sa0 is the 'public tape drive' but all other tape devices are reserved for system backups and can only be used by the admin). 3) Purge all persistence information for a particular instance easily, and selective purge persistence information with an operation as simple as editing a text file. 4) Use chmod, chgrp, ln, mv on dev nodes just as can be done today and have those operations persistently reported. 5) Express more complicated policies (including chmod, chown, ln -s, etc type operations) using a regular expression based syntax (/dev/r?sa[0-9].* have particular attributes). 6) Prevent new device node creation, modify new device default permission and whiteout behavior via mount options. > 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 3rd party developer would rely on the policy tools as shipped by the system. If the end user decides not to use those tools, it becomes the end-users problem (don't DO that!). > 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 ? Yes. > So far I hear the following clear opinion: > > Joerg: non-persistent > DavidG: non-persistent I don't think that either of their positions are that cut and dried. > 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). The device node disappears immediately for any potential new users. Anyone holding the device node open is redirected to deadfs so that they can receive EIO, etc. ad infinitum and the underlying device can safely clean up any per-instance data. There may be cases where you don't want the client to be redirected to deadfs before seeing EIO (perhaps you want to allow an ioctl to fetch state about the reason you are going away), but it should be possible to signal to devfs that no new lookups should find this node. Devices of this type would have to defer the creation of a replacement instance until the first one has fully cycled through last close, but this is a tractable problem (CAM does this right now). > So the "go away" event is NOT triggered by the disappearance of the > device node in /dev, that complicates matters a bit. The daemon should be able to see that the node has disappeared even if the FS accessing that device has not been unmounted yet. I seem to recall that umount doesn't require the device node in order to do its job. > 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 :-) If you don't want us to talk about something, don't bring it up. This is especially true if you expect the moderator of a moderated list to limit the scope of the discussion. [There is only one case where I'll drop posts I feel are relevant and bring extra information to the choice at hand: If a strict policy for the thread has been stated in the initial message in the thread and the new posts don't fit that policy. IMO, dropping those posts otherwise would neither be fair to the readers of the list, not to the posters. -EE] -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 3 09:40:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA17397 for freebsd-arch-outgoing; Sun, 3 Jan 1999 09:40:31 -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 JAA17387 for ; Sun, 3 Jan 1999 09:40:29 -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 SAA17167 for ; Sun, 3 Jan 1999 18:40:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA99083 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 18:40:03 +0100 (MET) 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 JAA16129 for ; Sun, 3 Jan 1999 09:30: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 SAA17065 for ; Sun, 3 Jan 1999 18:29:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA99030 for arch@FreeBSD.org; Sun, 3 Jan 1999 18:29:49 +0100 (MET) Message-ID: <19990103182949.T88411@follo.net> Date: Sun, 3 Jan 1999 18:29:49 +0100 From: Eivind Eklund To: arch@FreeBSD.ORG Subject: Administrativa Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG My policy on approval: I'll approve (in the sense that I will try to bring it to the list after suitable editing) anything I deem bring extra information to a topic, as long as it is not in violation of policy for the thread. To have a formal policy for a thread, the thread initiator must state the policy clearly in the initial message in the thread. A note on wasting time: Please try to keep the discussions that are Cc:'ed freebsd-arch based on the messages that actually are approved to freebsd-arch. That is, replying to a Cc: you got (instead of messages sent to the actual list) is a Bad Idea. I've had to drop a couple of entire subthreads run between people on the To/Cc list; this isn't a large hassle for me, but it waste the time of the people writing. (I've thought of setting Reply-To for the list, but that isn't a good solution, so I'll start off with just an appeal for sense.) On submissions: All submissions are either approved, or I send a message to the author explaining why it wasn't approved. If you don't get either, get in touch - messages are not supposed to be silently dropped. On editing: I will fix minor spelling problems, normalize formatting/quotations, cut excessive quotation, and possibly fix up minor, obvious grammatical problems (misplaced commas and similar). Anything requiring more editing than that will be returned to the author for re-submission. I will not do anything that I consider to change the overall tone of the message. If you have issues with how I moderate the list or what I do to your post, please contact me so we can try to work out how to fix it. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 3 09:50:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA18385 for freebsd-arch-outgoing; Sun, 3 Jan 1999 09:50: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 JAA18289 for ; Sun, 3 Jan 1999 09:49:59 -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 SAA17255 for ; Sun, 3 Jan 1999 18:49:30 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA99122 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 18:49:30 +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 CAA05175 for ; Sun, 3 Jan 1999 02:09:54 -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 LAA09107; Sun, 3 Jan 1999 11:07:24 +0100 (CET) To: arch@FreeBSD.ORG Mail-Followup-To: arch@FreeBSD.ORG X-To: Nate Williams X-cc: Chuck Robey , arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 23:25:13 MST." <199901030625.XAA18116@mt.sri.com> Date: Sun, 03 Jan 1999 11:07:24 +0100 Message-ID: <9105.915358044@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901030625.XAA18116@mt.sri.com>, Nate Williams writes: >> > 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). > >That's not true (think modems), and putting 'permission' policy into >mount and ifconfig is utter silliness. It sure is the case. And please try to read, in particular on the lines, we're not talking about putting permissions in ifconfig or mount but about a daemon which can amongst other things set the permissions and call ifconfig/mount. >Assuming we agree that a non-persistent DEVFS is acceptable, we still >need some way of setting policy, and so far the most common solution is >the rc.* solution, which is inadequate. No, the question is whether "chmod 777 /dev/null" will succeed or not. >> 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 ? > >Yes. And would you care to elaborate on why ? -- 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 Sun Jan 3 11:12:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26118 for freebsd-arch-outgoing; Sun, 3 Jan 1999 11:12: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 LAA26109 for ; Sun, 3 Jan 1999 11:12: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 UAA17977 for ; Sun, 3 Jan 1999 20:11:34 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA99433 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 20:11:33 +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 WAA17858 for ; Sat, 2 Jan 1999 22:25:56 -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 XAA22123; Sat, 2 Jan 1999 23:25:13 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id XAA18116; Sat, 2 Jan 1999 23:25:13 -0700 Date: Sat, 2 Jan 1999 23:25:13 -0700 Message-Id: <199901030625.XAA18116@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG X-To: Poul-Henning Kamp X-Cc: Chuck Robey , arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-Reply-To: <6040.915273405@critter.freebsd.dk> References: <6040.915273405@critter.freebsd.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> 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). That's not true (think modems), and putting 'permission' policy into mount and ifconfig is utter silliness. > 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. Sure it does. It's the biggest downfall with persistence mechanism that has been proposed so far, since we need *some* way of establishing security/local policy. Assuming we agree that a non-persistent DEVFS is acceptable, we still need some way of setting policy, and so far the most common solution is the rc.* solution, which is inadequate. > 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 ? Yes. > So far I hear the following clear opinion: > > Joerg: non-persistent > DavidG: non-persistent > Poul-Henning: non-persistent It matters more what the users want, or FreeBSD will go the way of the Dodo bird and NeXT-OS. 'It was nice for awhile, but the developers didn't want to fix the hard problems and instead opted for a solution that was *worse* than the existing scheme.' That is my opinion of the what has been portrayed as of late by a number of developers, and which you continue to portray. Non-persistent DEVFS is the most critical portion of POLA. For those developers who use it in embedded systems (wcarchive, you, etc...), non-persistence isn't important simply because you are capable of setting policy due to your familiarity with the system. But, your average user (and above-average user) will have a difficult time, and/or make their system insecure. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 3 11:21:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA26936 for freebsd-arch-outgoing; Sun, 3 Jan 1999 11:21:28 -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 LAA26931 for ; Sun, 3 Jan 1999 11:21:26 -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 UAA18063 for ; Sun, 3 Jan 1999 20:20:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA99499 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 20:20:54 +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 SAA03944 for ; Sat, 2 Jan 1999 18:52:59 -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 KAA06791 for ; Sun, 3 Jan 1999 10:52:10 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199901030252.KAA06791@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 12:43:31 +0100." <19990102124331.02468@uriah.heep.sax.de> Date: Sun, 03 Jan 1999 10:52:05 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG J Wunsch wrote: > 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 ;-) Just repeating something I said earlier. I think it would be better to enable drivers to choose a "class" much moreso than permissions. This allows default uid/gid/mode etc to be exported to userland, but still comes up with a functional devfs (600, root, wheel) at boot and single user. If we can do a: sysctl -w vfs.devfs.class.console.uid=`id -u peter` and have all past and future console related devices being owned by uid 433 instead of 0, then I'd be as happy as a clam. However, doing an explicit 'chmod joebloggs /dev/ttyv8' would assign it a uid and sperate it from class updates via sysctl. An /etc/*rc* script would handle setting permissions of the default classes at boot, and any explicit overrides. [I'm somewhat doubtfully letting this repeat through, given that the concept seems interesting and some people might have lost some of the core of the other (long) mail in the heat of the moment. -EE] Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 3 13:19:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA08790 for freebsd-arch-outgoing; Sun, 3 Jan 1999 13:19: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 NAA08785 for ; Sun, 3 Jan 1999 13:19:06 -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 WAA19318 for ; Sun, 3 Jan 1999 22:18:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA00273 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 22:18:39 +0100 (MET) Received: from dingo.cdrom.com (castles317.castles.com [208.214.167.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06128 for ; Sun, 3 Jan 1999 12:48:42 -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 MAA07212; Sun, 3 Jan 1999 12:42:12 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901032042.MAA07212@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Poul-Henning Kamp cc: Chuck Robey , arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sat, 02 Jan 1999 11:36:45 +0100." <6040.915273405@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Jan 1999 12:42:11 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > From: Chuck Robey > > > > First, Poul, will you agree that the opinion of the great majority of > > developers want persistence? > > No, I will not. It's irrelevant whether you agree or not. Most of the ones that have expressed a concern see the ability to control the behaviour of the DEVFS as desirable. Many of those schemes don't really qualify as "persistence" per se, but attempt to address the same set of problems. More to the point, we have on record some very strong sentiment from the user community (remember them?) indicating that the ability to address these problems is very important to them. > > 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. You _might_ want it to be possible to bring nodes back in a chroot jail, since chroot jails are used for considerably more diverse purposes than simply security. Hence the need (as you've already divined) for both 'whiteout' and outright permanent revocation. However, as you point out, this is indeed an implementation issue. > 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 ? I don't see a clear need to emulate things to this level. A mechanism where it's possible for the administrator to say "I want all sio* devices to come up 664 root/dialer" is more than adequate for the majority of cases. Peter's class model works for this; think of it like a 'umask' for devices. > I think I hear Mike Smith saying: > > "I want persistence for persistence sake" Thanks for the slap. No, I want tunable defaults as a practical alternative solution to the problems that persistence tries to address. I don't think we have enough mileage on the devfs scenario (trivial anecdotes aside) to make any hard design decisions at this point in time. -- \\ 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 Sun Jan 3 13:25:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09481 for freebsd-arch-outgoing; Sun, 3 Jan 1999 13:25: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 NAA09456 for ; Sun, 3 Jan 1999 13:25: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 WAA19352 for ; Sun, 3 Jan 1999 22:24:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA00304 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 22:24:47 +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 NAA08219 for ; Sun, 3 Jan 1999 13:11:51 -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 0zwuns-0002vP-00; Sun, 3 Jan 1999 14:11:16 -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 OAA57058 for ; Sun, 3 Jan 1999 14:09:16 -0700 (MST) Message-Id: <199901032109.OAA57058@harmony.village.org> To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG Subject: Implementing a DEVFS daemon Date: Sun, 03 Jan 1999 14:09:16 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG One idea that I've not seen talked about would be as follows. It is a variation on phk's /etc/dev.d discussions, but I think is simpler, more powerful and violates POLA less. Plus I'll offer a couple of examples of why I'd want devices to have persistent attributes. I do not assume that the underlying devfs actually supports persistence beyond the current boot. Consider having a daemon that saves the state of a particular /devfs tree. This daemon will wake up every now and again and read the /devfs tree. When it notices changes, it will record them in its database. This database will be in text format for easy editing. Then when the system starts up, it will use this database to set the permissions of devices as they arrive, if not initially present. This way to change the ownership of /dev/ttyd1, I say chown root.redheads /dev/ttyd1. The daemon notices after a short time and then for ever after when the system comes up /dev/ttyd1 is root.redheads as its devices. "for ever after" also includes when the device goes away for a while (say a modem pulled from the system to loan to a friend or a trip) but does not extend past other events that modify the device's attributes in a conflicting way (say I chgrp the device to losh-brothers). This gets the persisting part out of devfs and places it into a central daemon. This daemon would be the only one that would munge the devices' permissions after they appear, at least for devices that it knows about. No need to muck with mount, ifconfig, pccardd, etc to get things to work right. For devices that it doesn't know about, I can imagine that a useful extension would be a single script. /etc/device.conf (say) that would be executed with one argument (the node that was added to the tree). The shell script can then deal with setting default permissions. Should device classes be found to be desirable, then a simple c program could be used to ask a node in the /devfs tree what its device class is and then the shell script could use that information to set policy for that device. This would be simpler and easier than the daemon design that phk had talked about here. It would only add two files to /etc (device.conf and device.persist), rather than a tree and it would centralize administrative decisions for classes of devices. In addition, it would come very close to not violating POLA as the publish interface to setting and changing device permissions doesn't change and is consistent with other unixes. It would also be smaller, simpler and easier to write and easier to do a security audit on. The impact to the underlying devfs implementation is that it needs to honor chown, chmod, chgrp and symbolic links. It needn't worry about how things are persistent or not persistent. It just needs to manage trees of devices and allow symbolic links in that tree. It would also need to give the daemon the ability to ask if a node in the tree was a device or not, so would need to support stat(2) as well. I believe this is the minimal set of things needed. Also I assume that all devices are created by devfs either 000 or with the mode that the device tells devfs about, should it care to do so. I can think of many ways to optimize this to improve latency and reduce processing overhead, but for a first cut this would likely be unnecessary. Also, there is a "race" here. If I chmod 777 /dev/ttyd1 and then turn the machine off, it may or may not record that new mode. Re: Why have not information come back: I think that it is desirable to have permissions come back when you chmod 774 a device. If this device is a pc-card device, it won't exist when the system boots, but is added later by pccard. It might not even exist over several reboots of the machine, but when it does come back, I want the same permissions it had when it went away, just like things do today. I usually have a network card in my 1 pccard slot, but when I travel, I take the network card out and put a modem card in. I do not want to have to run my modem accessing programs as root or chown/chmod the device every time I stick it into the machine. Likewise, if I have a scanner on my SCSI bus that I don't always turn on, or share between many machines. When it goes away for a while and then comes back, I find it desirable to have the same view as it had before. I think the case of purchasing a single device, trying it out, then tossing it for months then buying another device months later is a much rarer case than the above cases and should require the exceptional activity rather than vice versa. Comments? Warner P.S. I'll be happy to put together a preliminary implementation of this daemon for people to play with. [It seemed appropriate to split this off from the initial thread. -EE] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Jan 3 13:26:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA09591 for freebsd-arch-outgoing; Sun, 3 Jan 1999 13:26:20 -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 NAA09586 for ; Sun, 3 Jan 1999 13:26:19 -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 WAA19381 for ; Sun, 3 Jan 1999 22:25:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA00331 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 22:25:53 +0100 (MET) Received: from dingo.cdrom.com (castles317.castles.com [208.214.167.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA04456 for ; Sun, 3 Jan 1999 12:36:45 -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 MAA07162; Sun, 3 Jan 1999 12:33:33 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199901032033.MAA07162@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 X-To: Warner Losh To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Fri, 01 Jan 1999 22:12:23 MST." <199901020512.WAA09287@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Jan 1999 12:33:32 -0800 From: Mike Smith Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 doesn't generalise, unfortunately. There's no guarantee that a new instance of the same device is the same hardware, so we can't make that assumption. If the administrator can, then they need to encode that in their local modifications to the tunable defaults. That sort of "just like a filesystem" semantic is desirable in some cases, but certainly not all, and possibly not even most. > 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. Until version 0 is implemented and deployed, we have no practical basis on which to make the design decisions for version 1. Attempting to make those decisions now, and more to the point, delaying version 0 until we have made those decisions, brings us to the point of gridlock. -- \\ 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 Sun Jan 3 14:11:27 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA13481 for freebsd-arch-outgoing; Sun, 3 Jan 1999 14:11:27 -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 OAA13476 for ; Sun, 3 Jan 1999 14:11:25 -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 XAA19809 for ; Sun, 3 Jan 1999 23:11:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA00589 for freebsd-arch@freebsd.org; Sun, 3 Jan 1999 23:10:59 +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 NAA11963 for ; Sun, 3 Jan 1999 13:51:28 -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 WAA14536 for freebsd-arch@FreeBSD.ORG; Sun, 3 Jan 1999 22:51:02 +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 WAA14704; Sun, 3 Jan 1999 22:28:49 +0100 (MET) (envelope-from j) Message-ID: <19990103222848.53389@uriah.heep.sax.de> Date: Sun, 3 Jan 1999 22:28:48 +0100 From: J Wunsch To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Reply-To: Joerg Wunsch References: <19990102124331.02468@uriah.heep.sax.de> <199901030252.KAA06791@spinner.netplex.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199901030252.KAA06791@spinner.netplex.com.au>; from Peter Wemm on Sun, Jan 03, 1999 at 10:52:05AM +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 Peter Wemm wrote: > Just repeating something I said earlier. I think it would be better to > enable drivers to choose a "class" much moreso than permissions. ... > > If we can do a: > sysctl -w vfs.devfs.class.console.uid=`id -u peter` > and have all past and future console related devices being owned by uid > 433 instead of 0, then I'd be as happy as a clam. I can live with a vehicle like sysctl spamm^H^H^H^H^Hproviding the kernel with UIDs. My only problem is that the current DEVFS implementation spams the kernel with a bunch of UIDs/GIDs the kernel shouldn't maintain itself. -- 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 Mon Jan 4 07:42:20 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA27540 for freebsd-arch-outgoing; Mon, 4 Jan 1999 07:42:20 -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 HAA27533 for ; Mon, 4 Jan 1999 07:42:17 -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 QAA16026 for ; Mon, 4 Jan 1999 16:41:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA05114 for freebsd-arch@freebsd.org; Mon, 4 Jan 1999 16:41:49 +0100 (MET) Received: from picasso.wcape.school.za (picasso.wcape.school.za [196.21.102.12]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA00714 for ; Sun, 3 Jan 1999 22:23:01 -0800 (PST) (envelope-from pvh@leftside.wcape.school.za) Received: from uucp by picasso.wcape.school.za with local-rmail (Exim 2.05 #1) id 0zx3PJ-0005p6-00 for freebsd-arch@FreeBSD.ORG; Mon, 4 Jan 1999 08:22:29 +0200 Received: from localhost (pvh@localhost) by leftside.wcape.school.za (8.8.8/8.8.4) with SMTP id IAA00985 for ; Mon, 4 Jan 1999 08:19:10 +0200 (SAT) Date: Mon, 4 Jan 1999 08:19:10 +0200 (SAT) From: Peter van Heusden To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-Reply-To: <19990103222848.53389@uriah.heep.sax.de> 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 As I understand it, the core philosophical points behind the current arguments are: 1) /dev is a 'view' on a particular set of data. DEVFS currently transforms the kernel database of device information into files in /dev. 2) Simply knowing which devices exist is not enough. It is necessary to store information with regards to admin policy decisions such as security policies (permissions), well-known names (symbolic links), and so forth. Given this basis, the debate clearly seems to be about how to store the information mentioned in point 2. Various schemes have been suggested - I'd just like to put in my 2c by arguing against the idea of storing this data in a shell script, on the basis that what should be important here is the storage of the policy, not the actions which would implement the policy. My experience with writing a WWW interface to FreeBSD made me realise that shells scripts for configuration (e.g. /etc/rc.conf) are a big minefield. Anything that wants to alter /etc/rc.conf has to potentially be able to understand the language of sh. I would strongly argue that however persistent policy storage is implemented (by a daemon of some description, by the fs mount command, etc), the information should be stored in an ascii file with some well known, but simple, format. That would allow both users and programs to easy interact with, and alter, the data. Peter -- Peter van Heusden | Its the 90's, and collective action is STILL cool! pvh@leftside.wcape.school.za | Get active in your union today! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 04:29:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09304 for freebsd-arch-outgoing; Tue, 5 Jan 1999 04:29:31 -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 EAA09297 for ; Tue, 5 Jan 1999 04:29:22 -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 NAA09773 for ; Tue, 5 Jan 1999 13:28:53 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA14192 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 13:28:51 +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 SAA09438 for ; Sun, 3 Jan 1999 18:17:39 -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 TAA29522; Sun, 3 Jan 1999 19:17:13 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id TAA20679; Sun, 3 Jan 1999 19:17:13 -0700 Date: Sun, 3 Jan 1999 19:17:13 -0700 Message-Id: <199901040217.TAA20679@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG X-To: Warner Losh Subject: Re: Implementing a DEVFS daemon In-Reply-To: <199901032109.OAA57058@harmony.village.org> References: <199901032109.OAA57058@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 > Consider having a daemon that saves the state of a particular /devfs > tree. This daemon will wake up every now and again and read the > /devfs tree. When it notices changes, it will record them in its > database. This database will be in text format for easy editing. Any chance that DEVFS could throw a symbol in /proc (or even in /dev) so that it could through a 'select()' event to the daemon to cause it to re-read the /devfs? (Just a nit). This is how the APM system works, and it keeps the daemon from having to continually poll the kernel and burn up CPU cycles for no good reason. Otherwise, since it seems to be giving me what I believe the userbase desires (persistence w/out requiring learning 'Yet-Another FreeBSD centric configuration') it sounds good. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 04:32:50 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA09999 for freebsd-arch-outgoing; Tue, 5 Jan 1999 04:32:50 -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 EAA09994 for ; Tue, 5 Jan 1999 04:32:48 -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 NAA10163 for ; Tue, 5 Jan 1999 13:32:18 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id NAA14229 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 13:32:18 +0100 (MET) Received: (from jmb@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02594; Sun, 3 Jan 1999 16:55:45 -0800 (PST) (envelope-from jmb) Date: Sun, 3 Jan 1999 16:55:45 -0800 (PST) Message-Id: <199901040055.QAA02594@hub.freebsd.org> From: "Jonathan M. Bresler" To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG X-To: Warner Losh In-reply-to: <199901032109.OAA57058@harmony.village.org> (message from Warner Losh on Sun, 03 Jan 1999 14:09:16 -0700) Subject: Re: Implementing a DEVFS daemon References: <199901032109.OAA57058@harmony.village.org> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Consider having a daemon that saves the state of a particular /devfs > tree. This daemon will wake up every now and again and read the > /devfs tree. When it notices changes, it will record them in its > database. This database will be in text format for easy editing. The timing issues seem to be ugly to me. It would be nice if shutdown forced this daemon to roam over the /devfs tree. It almost sounds like we need upcalls from the kernel to the daemon -- at which point I wonder why the daemon is not in the kernel. I still have to read 99% of the kernel, so if this is wacky tell me and I'll shut up. jmb [Personally, I think this sounds like the perfect excuse for implementing file notification in FreeBSD. Somebody at McKusicks course was working on that - if that person is reading this, please speak up! -EE] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 06:01:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA17854 for freebsd-arch-outgoing; Tue, 5 Jan 1999 06:01:53 -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 GAA17848 for ; Tue, 5 Jan 1999 06:01:50 -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 PAA15419 for ; Tue, 5 Jan 1999 15:01:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA14853 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 15:01:20 +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 FAA16273 for ; Tue, 5 Jan 1999 05:48:26 -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 OAA19626 for ; Tue, 5 Jan 1999 14:47:20 +0100 (CET) To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Sun, 03 Jan 1999 12:33:32 PST." <199901032033.MAA07162@dingo.cdrom.com> Date: Tue, 05 Jan 1999 14:47:20 +0100 Message-ID: <19624.915544040@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Well, summary #2: 1. Nobody against DEVFS as standard so far. 2. All talk of persistence implemented in the kernel has stopped. Cool, that is much further than -core has managed to get in 2.5 years. The next thing to tackle is the "devd": what it does. (NB: NOT HOW IT DOES IT, I will urge the moderator to try to stay close to this policy for this discussion, thankyou!) Some thinking points: * "devd" must be optional, for embedded applications where space is tight we don't want to force people to run it. It could also quickly become a problem for machines with many chroot jails if they needed a devd for each, so the "/etc/dev.rc" mode of config must be an option. * "device classes", are probably a good idea, although I have a hard time finding more classes than "disk" and "tty" and "console associated", where the latter covers mice, sound, keyboards, cameras and so on. I am against implementing them in the kernel because it should not be needed to change the kernel to introduce a new class, and it isn't a job for the kernel anyway in my eyes. So, lets brainstorm the "devd" concept a bit, where does it come into play ? * Device node permission policy implementation ("I want disks to be 640 root/operator") * Device node permission persistence ("He did a ``chmod 777 /dev/rwd0a'', give it to him after every reboot if persistence is enabled") * Device presence handling ("Ahh, A CD in the drive, lets see: mount that under /cd2/386bsd-0.0" and "umount -f /cd2/386bsd-0.0") This third point needs a good amount of thought from us all, and is probably the only one we haven't already resolved by and large: Some of the obvious things you can do with this is: * Download microcode * mount/unmount disks/cd/zip/whathaveyou * start getty or ppp processes on serial ports (pccard modems!) * handle "configuration sets", ie "notebook docked" vs "notebook undocked" vs "notebook with pcmcia ethernet at customer #1 network" and so on. Some of this is as trivial as "locate the right command for this device and execute it" no sweat. Trouble starts with PnP, Pccard, USB and cardbus. PnP for instance will send a event before undocking is physically allowed (they learned that much from the PCMCIA mistake :-). It sounds to me like this is a "devd" job. Mostly because I hate the idea of having too many daemons hanging around, but more probably because so many of the issues are in the same corner of the field that if we don't integrate these things, we will have to make them talk together anyway to avoid flattened toes. Does anybody see a way to meta-ize devd (as in "inetd") to avoid having all the code for the various ugly standards loaded by default, but still retain a good integrated view of things ? (people without detailed knowledge of PnP, PCCARD, USB need not bother with an answer). -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 07:23:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA26247 for freebsd-arch-outgoing; Tue, 5 Jan 1999 07:23: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 HAA26242 for ; Tue, 5 Jan 1999 07:23:16 -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 QAA17195 for ; Tue, 5 Jan 1999 16:22:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA15570 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 16:22:42 +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 HAA25039 for ; Tue, 5 Jan 1999 07:11:02 -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 XAA21446 for ; Tue, 5 Jan 1999 23:10:31 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199901051510.XAA21446@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Tue, 05 Jan 1999 14:47:20 +0100." <19624.915544040@critter.freebsd.dk> Date: Tue, 05 Jan 1999 23:10:30 +0800 From: Peter Wemm Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Poul-Henning Kamp wrote: [..] > Some thinking points: > > * "devd" must be optional, for embedded applications where space is > tight we don't want to force people to run it. It could also > quickly become a problem for machines with many chroot jails if > they needed a devd for each, so the "/etc/dev.rc" mode of config > must be an option. > > * "device classes", are probably a good idea, although I have a hard > time finding more classes than "disk" and "tty" and "console associated" , > where the latter covers mice, sound, keyboards, cameras and so on. > I am against implementing them in the kernel because it should not > be needed to change the kernel to introduce a new class, and it isn't > a job for the kernel anyway in my eyes. For devd to be optional, then the kernel needs to help a little so that /etc/rc can do enough to result in a sane and workable system. Otherwise, devd isn't going to have a clue what a "blurf" device is when it gets loaded or appears on a dynamic bus. Other important classes are that spring to mind: cua (quite different to tty), "tape" (different to disk). There are some others that are not so clear, the floppy and cdrom being one. Are they a "disk" or "console related"? It certainly could be important since if the system sees partitions/slices on it, then it has to know what to call them. On a system without devd running, one would have to chmod -R 666 /dev/fd* /dev/rfd* every time the floppy was changed. However, being able to set the modes via a sysctl would solve that without needing devd. I know the users would have it shot if that was the case. Implementing class support in the kernel should be almost trivial compared to the devfs task itself. I think that a driver should be able to name it's class (creating it if it doesn't exist yet), just like the VFS's choose their own name. An additional concern.. There are two types of persistance.. The first is persistance across reboot (IMHO, this is not needed with a decent backing infrastructure). The second is persistance across add/remove of nodes during the time the machine is up (eg: usb devices, partition/ slices that change on removable media or as a result of partitioning). The second would be sort-of covered by devd, as long as the config file was edited in advance. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 09:26:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA09402 for freebsd-arch-outgoing; Tue, 5 Jan 1999 09:26:42 -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 JAA09397 for ; Tue, 5 Jan 1999 09:26:40 -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 SAA18925 for ; Tue, 5 Jan 1999 18:26:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA16093 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 18:26:12 +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 JAA08975 for ; Tue, 5 Jan 1999 09:21:24 -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 SAA20482 for ; Tue, 5 Jan 1999 18:20:18 +0100 (CET) To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Tue, 05 Jan 1999 23:10:30 +0800." <199901051510.XAA21446@spinner.netplex.com.au> Date: Tue, 05 Jan 1999 18:20:17 +0100 Message-ID: <20480.915556817@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901051510.XAA21446@spinner.netplex.com.au>, Peter Wemm writes: > For devd to be optional, then the kernel needs to help a little so > that /etc/rc can do enough to result in a sane and workable > system. Otherwise, devd isn't going to have a clue what a "blurf" > device is when it gets loaded or appears on a dynamic bus. Don't you mix things here ? If you don't have a devd running you may not know what class a device wants to belong to, but since this is intended only for "otherwise limited functionality", ie embedded or chroot environments I don't think that is a big problem. If you have a devd it needs to be able to figure out which class a particular device belongs to. I either case I can't see why the kernel part of devfs should know and communicate more than the name and the class. All the sysctl stuff seems superfluous to me. How will you handle the case of chroot with a different policy with a sysctl anyway ? If anything it would have to be (per) mount options, but all I can see it would be is a "devd-lite-in-the-kernel" which is not very useful as I see it... > Other important classes are that spring to mind: cua (quite > different to tty), "tape" (different to disk). There are some > others that are not so clear, the floppy and cdrom being one. Are > they a "disk" or "console related"? Which is why I would rather have the classes not even exist in the kernel, but be expressed by a file in userland. I don't see much benefit for the kernel knowing... > Implementing class support in the kernel should be almost trivial > compared to the devfs task itself. No, actually not. > An additional concern.. There are two types of persistence.. The > first is persistence across reboot (IMHO, this is not needed with a > decent backing infrastructure). > The second is persistence across add/remove of nodes during the time > the machine is up (eg: usb devices, partition/ slices that change on > removable media or as a result of partitioning). The second would > be sort-of covered by devd, as long as the config file was edited in > advance. Well, I think we should try to keep the two terms "policy" and "persistence" covering two different concepts: policy: A stated intent of permissions (and possibly actions) relating to a well defined (but possibly instance wildcarded) set of nodes. (your second item) persistence: "random" changes to the permissions (or nodes/links/symlinks/directories created/deleted) by an authorized user which supersede the applicable policy. (your first item) -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 09:56:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA12745 for freebsd-arch-outgoing; Tue, 5 Jan 1999 09:56: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 JAA12740 for ; Tue, 5 Jan 1999 09:56: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 SAA19393 for ; Tue, 5 Jan 1999 18:56:05 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA16289 for freebsd-arch@freebsd.org; Tue, 5 Jan 1999 18:56:04 +0100 (MET) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA11395 for ; Tue, 5 Jan 1999 09:43:56 -0800 (PST) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (haldjas.folklore.ee [172.17.2.1] (may be forged)) by haldjas.folklore.ee (8.8.8/8.8.4) with SMTP id TAA06050; Tue, 5 Jan 1999 19:43:01 +0200 (EET) Date: Tue, 5 Jan 1999 19:43:01 +0200 (EET) From: Narvi X-To: Peter Wemm To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-Reply-To: <199901051510.XAA21446@spinner.netplex.com.au> 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 Tue, 5 Jan 1999, Peter Wemm wrote: > Poul-Henning Kamp wrote: > [..] >> Some thinking points: >> [snip] >> * "device classes", are probably a good idea, although I have a >> hard time finding more classes than "disk" and "tty" and >> "console associated", where the latter covers mice, sound, >> keyboards, cameras and so on. While mice, sound and keyboard may indeed be related to the console, I fail to find any reason why a camera should be "console associated". While video conferencing and video editing certainly are interesting and console associated, these are but some of the ways cameras get used. Cameras are much rather class "data acquisition" or class misc rather than class "console associated". Device classes may be useful, but creating a set of device classes that both covers most devices, is meaningful and extensible is not trivial. [snip] > Other important classes are that spring to mind: cua (quite different to > tty), "tape" (different to disk). There are some others that are not so > clear, the floppy and cdrom being one. Are they a "disk" or "console > related"? It certainly could be important since if the system sees Leaving floppy aside, a cd-rom can be both class "disk" and class "console associated", indeed, there could be cd-roms in both "classes" present in the system at the same time. A cd-rom device in a cd-rom tower for which the system is no more than the interface to the network and cache is definitely class "disk". The cd-rom in the desktop computer that has most of the time an audio cd in it and occasionally a data cd or in which data cd-roms get changed often is "console associated", especially if the machine is "public". How will multi-class devices be treated? Or should we have class "cd-rom"? > partitions/slices on it, then it has to know what to call them. On a > system without devd running, one would have to > chmod -R 666 /dev/fd* /dev/rfd* > every time the floppy was changed. However, being able to set the modes via > a sysctl would solve that without needing devd. I know the users would > have it shot if that was the case. Implementing class support in the kernel > should be almost trivial compared to the devfs task itself. I think that a > driver should be able to name it's class (creating it if it doesn't exist > yet), just like the VFS's choose their own name. > Anything single-purpose can know it's class. Everything that can be used in multiple classes must be able to migrate classes, possibly instance at a time. Will root be able to tell the device to leave behind it's silly prejudices and start behaving like it should and joining another device class? Will it be able to tell some instances of the device to join another class? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 16:17:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA09727 for freebsd-arch-outgoing; Tue, 5 Jan 1999 16:17:30 -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 QAA09722 for ; Tue, 5 Jan 1999 16:17:26 -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 BAA24067 for ; Wed, 6 Jan 1999 01:16:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA23689 for freebsd-arch@freebsd.org; Wed, 6 Jan 1999 01:16:57 +0100 (MET) Received: from gilgamesch.bik-gmbh.de (gilgamesch.bik-gmbh.de [194.233.237.91]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA05105 for ; Tue, 5 Jan 1999 08:48:03 -0800 (PST) (envelope-from cracauer@gilgamesch.bik-gmbh.de) Received: (from cracauer@localhost) by gilgamesch.bik-gmbh.de (8.8.8/8.7.3) id RAA22563; Tue, 5 Jan 1999 17:47:29 +0100 (MET) Message-ID: <19990105174729.A22338@cons.org> Date: Tue, 5 Jan 1999 17:47:29 +0100 From: Martin Cracauer X-To: Alex Zepeda To: freebsd-arch@FreeBSD.ORG Mail-Followup-To: freebsd-arch@FreeBSD.ORG Subject: C++ compatible include files (Re: egcs chokes on netinet/in.h) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Alex Zepeda on Thu, Dec 31, 1998 at 01:49:11AM -0800 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [moved to -arch] In , Alex Zepeda wrote: > /usr/include/netinet/in.h:291: ANSI C++ forbids data member `ip_opts' with > same name as enclosing class > struct ip_opts { > struct in_addr ip_dst; /* first hop, 0 w/o src rt */ > char ip_opts[40]; /* actually variable in size */ There's also the key_t issue, a struct in console.h and a typedef to long in types.h (for SysV IPC). Since C++ handles structs automatically as 'typedef struct structname structname;', this breaks C++ as well. I think we need a decision whether we will fix FreeBSD include files to be compatible with ANSI C++. If we decide to do so, the options are: - change the definion - change the definition for C++ only - disable the definition for C++ In my opinion, only the first one makes sense and also in my opinion we should have C++-compatible include files. In case of a decision in this line, I volunteer to: - search for all uses of ip_opts and change these to the new name of the second member in the base FreeBSD system. [If we rename the second member]. - Do the same for key_t. If we rename the struct for the console code I'll change everything in the base FreeBSD system, add a temporary patch to the XFree port and the Linux svga lib and notify XFree to use the new name in the next release. - I'll also fix any port that I suspect will use these or that people point to. This includes monitoring -bugs and -ports for such reports. - Of course, commits are done after a successful `make world`. Yes, I use C++ sometimes :-) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 16:22:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10403 for freebsd-arch-outgoing; Tue, 5 Jan 1999 16:22: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 QAA10398 for ; Tue, 5 Jan 1999 16:22:31 -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 BAA24111 for ; Wed, 6 Jan 1999 01:22:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA23724 for freebsd-arch@freebsd.org; Wed, 6 Jan 1999 01:22:03 +0100 (MET) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12439; Tue, 5 Jan 1999 04:57:14 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca7-163.ix.netcom.com [209.109.235.163]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id EAA08161; Tue, 5 Jan 1999 04:56:47 -0800 (PST) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.1/8.6.9) id EAA65568; Tue, 5 Jan 1999 04:56:44 -0800 (PST) Date: Tue, 5 Jan 1999 04:56:44 -0800 (PST) Message-Id: <199901051256.EAA65568@silvia.hip.berkeley.edu> To: jmb@FreeBSD.ORG CC: freebsd-arch@FreeBSD.ORG In-reply-to: <199901040055.QAA02594@hub.freebsd.org> (jmb@FreeBSD.ORG) Subject: Re: Implementing a DEVFS daemon From: asami@FreeBSD.ORG (Satoshi Asami) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: "Jonathan M. Bresler" > > The timing issues seem to be ugly to me. It would be nice if shutdown Yes. There could also be a potential security hole where people could take advantage of the time lag between the device appearance and this daemon changing its permissions. [This is not a problem if the devices arrive with 'suitable' permissions; ie, totally restricted. -EE] > forced this daemon to roam over the /devfs tree. It almost sounds > like we need upcalls from the kernel to the daemon -- at which point > I wonder why the daemon is not in the kernel. I still have to read > 99% of the kernel, so if this is wacky tell me and I'll shut up. Another hairy issue is how to keep the "easily editable ASCII" file in a consistent state. Suppose the daemon and the editor (videvfs?) need to lock the file before they make modifications. Now I edit the configuration file. While I'm editing it, the daemon is waiting, and when I finish, the daemon wakes up and tries to merge its changes. What if there is a merge conflict? What if I edited the file wrong and there is a syntax error? And if I hold the file too long for editing, there could be security implications too (see above). At which point I wonder why this is not done using pure filesystem semantics (chmod, chown, etc.). :) [chown/chmod is difficult to use to express policies, especially for devices that are not yet present. -EE] Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 16:27:02 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11085 for freebsd-arch-outgoing; Tue, 5 Jan 1999 16:27:02 -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 QAA11080 for ; Tue, 5 Jan 1999 16:27:00 -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 BAA24161 for ; Wed, 6 Jan 1999 01:26:33 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA23798 for freebsd-arch@freebsd.org; Wed, 6 Jan 1999 01:26:32 +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 KAA16287 for ; Tue, 5 Jan 1999 10:26:11 -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 0zxbAa-0004L7-00; Tue, 5 Jan 1999 11:25:32 -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 LAA13960; Tue, 5 Jan 1999 11:23:29 -0700 (MST) Message-Id: <199901051823.LAA13960@harmony.village.org> To: Poul-Henning Kamp Subject: Re: DEVFS, the time has come... Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Jan 1999 18:20:17 +0100." <20480.915556817@critter.freebsd.dk> References: <20480.915556817@critter.freebsd.dk> Date: Tue, 05 Jan 1999 11:23:29 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20480.915556817@critter.freebsd.dk> Poul-Henning Kamp writes: > I either case I can't see why the kernel part of devfs should know and > communicate more than the name and the class. All the sysctl stuff > seems superfluous to me. How will you handle the case of chroot > with a different policy with a sysctl anyway ? If anything it would > have to be (per) mount options, but all I can see it would be is > a "devd-lite-in-the-kernel" which is not very useful as I see it... I have two comments on this, and previous messages. 1) Given the design that I posted for what I called devfsd, sysctl is superfluous. 2) In an embedded environment, devfsd likely wouldn't be much fat compared to other things. I have a hard time believing that it would be much more than 32k-64k given the level of functionality that I'd like to place in it. Maybe this is the 'devd-lite' that phk is talking about, as I had no intention of supporting anything more than a 1-1 mapping of devices and permissions. I had no intention of supporting run a given shell script when device foo is created. Moving to that level likely would make devfsd something that is much larger than would be acceptable in an embedded environment. To recap the design for devfsd and what it requires of devfs: (1) devfsd will start by chmod/chown/chgrp the nodes it finds in its database. Otherwise it will exec a default script with one arg to get the node to have the right permissions. (2) devfsd will wakeup when a poll fires.[*] (3) devfsd will scan the tree, doing its thing ala startup, skipping those nodes that aren't new or changed. (1) devfs will honor chown, chgrp, chmod, symbolic links and mkdir. (2) devfs will cause the poll to fire[*] when one of these events happens. Nothing else. No sysctls are used. No device classes are needed (but could be implemented if someone wanted to do so). I should have a sample implementation of the above by the weekend, assuming that all goes well. The current devfs does (1), but not (2), so I'll likely "fake" that by some gross method for proof of concept. Warner [*] I'm being vague here because there are two ways this could happen. Justin talked about having a special poll event when a directory changed, which would be ideal. That isn't implemented yet. The other way is ala the apm stuff like Nate talked about. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Jan 5 16:28:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA11295 for freebsd-arch-outgoing; Tue, 5 Jan 1999 16:28:51 -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 QAA11275 for ; Tue, 5 Jan 1999 16:28:48 -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 BAA24183 for ; Wed, 6 Jan 1999 01:28:20 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA23820 for freebsd-arch@freebsd.org; Wed, 6 Jan 1999 01:28:20 +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 KAA18284 for ; Tue, 5 Jan 1999 10:43:09 -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 TAA20688 for ; Tue, 5 Jan 1999 19:42:02 +0100 (CET) To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Tue, 05 Jan 1999 11:23:29 MST." <199901051823.LAA13960@harmony.village.org> Date: Tue, 05 Jan 1999 19:42:02 +0100 Message-ID: <20686.915561722@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901051823.LAA13960@harmony.village.org>, Warner Losh writes: >2) In an embedded environment, devfsd likely wouldn't be much fat > compared to other things. I have a hard time believing that it > would be much more than 32k-64k given the level of functionality > that I'd like to place in it. Maybe this is the 'devd-lite' that > phk is talking about, as I had no intention of supporting anything > more than a 1-1 mapping of devices and permissions. I had no > intention of supporting run a given shell script when device foo is > created. Moving to that level likely would make devfsd something > that is much larger than would be acceptible in an embedded > environment. Well, that might be a usable model for embedded environments, but since you wouldn't offer PCCARD support, PnP support, or any of the other dynamic technologies which need high-level intelligence support, you wouldn't really be much better off than by using a shell script, so I don't think what you describe will be a much wanted solution... And please, could we try to aim the discussion at how we handle the advanced technologies in or out of devd ? The degraded cases are always easier to handle afterwards. [I somewhat doubtfully passed the previous message to give space to this appeal. -EE] -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Jan 6 00:27:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA06185 for freebsd-arch-outgoing; Wed, 6 Jan 1999 00:27: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 AAA06178 for ; Wed, 6 Jan 1999 00:27:19 -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 JAA28892 for ; Wed, 6 Jan 1999 09:26:50 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id JAA25553 for freebsd-arch@freebsd.org; Wed, 6 Jan 1999 09:26:49 +0100 (MET) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA07665 for ; Tue, 5 Jan 1999 20:10:06 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40340>; Wed, 6 Jan 1999 15:08:46 +1100 Date: Wed, 6 Jan 1999 15:09:21 +1100 From: Peter Jeremy Subject: Re: Implementing a DEVFS daemon To: arch@FreeBSD.ORG Message-Id: <99Jan6.150846est.40340@border.alcanet.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The moderator commented: [Security holes due to time between device arriving and devfsd fixing the permissions] >[This is not a problem if the devices arrive with 'suitable' >permissions; ie, totally restricted. -EE] Note that `totally restricted' is inappropriate for some devices: /dev/null is the most obvious one, but /dev/zero is another candidate. Admittedly, they shouldn't be magically appearing whilst the system is running. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 9 12:54:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA12578 for freebsd-arch-outgoing; Sat, 9 Jan 1999 12:54: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 MAA12569 for ; Sat, 9 Jan 1999 12:54: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 VAA05275 for ; Sat, 9 Jan 1999 21:53:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id VAA24995 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 21:53: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 TAA03276 for ; Tue, 5 Jan 1999 19:26:10 -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 0zxjbE-0004dj-00; Tue, 5 Jan 1999 20:25:36 -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 UAA19841 for ; Tue, 5 Jan 1999 20:23:37 -0700 (MST) Message-Id: <199901060323.UAA19841@harmony.village.org> Subject: Re: DEVFS, the time has come... To: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Tue, 05 Jan 1999 19:42:02 +0100." <20686.915561722@critter.freebsd.dk> References: <20686.915561722@critter.freebsd.dk> Date: Tue, 05 Jan 1999 20:23:37 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <20686.915561722@critter.freebsd.dk> Poul-Henning Kamp writes: > Well, that might be a usable model for embedded environments, but > since you wouldn't offer PCCARD support, PnP support, or any of > the other dynamic technologies which need high-level intelligence > support, you wouldn't really be much better off than by using a > shell script, so I don't think what you describe will be a much > wanted solution... I don't think that matters at all. pccard support is provided by pccardd while pnp support is provided by controller pnp0 in your config file. I disgree that you'd need more intellegence than what I've proposed. It will easily handle all the dynamic stuff that I can think of, of devices coming and going, etc. I don't see what pnp, pccard, etc have to do with this. They are orthoginal to the problem. My devfsd dynamically deals with devices coming and going. I also disagree that it won't buy you much beyond the shell script. It buys you two things: 1) the ability to chmod /dev/ttyd1 imp and have that change persist w/o any further action. This is certainly POLA for thise case. 2) The ability to insert a modem card and have it have its old permissions and ownerships restored. When the new device arrives in the tree, the daemon will set its meta data properly. However, this does raise an interesting question, which is what is the scope of this daemon? Warner [Sorry for the delay in handling this bunch of messages - technical mail-filtering error in my end. -EE] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 9 13:02:06 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13415 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:02:06 -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 NAA13396 for ; Sat, 9 Jan 1999 13:01:58 -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 WAA05322 for ; Sat, 9 Jan 1999 22:01:23 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25042 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:01:23 +0100 (MET) Received: from octopus.originative.co.uk (originat.demon.co.uk [158.152.220.9]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA03262 for ; Wed, 6 Jan 1999 08:33:09 -0800 (PST) (envelope-from paul@originative.co.uk) Received: by OCTOPUS with Internet Mail Service (5.5.1960.3) id ; Wed, 6 Jan 1999 16:31:23 -0000 Message-ID: From: Paul Richards To: freebsd-arch@FreeBSD.ORG Subject: RE: DEVFS, the time has come... Date: Wed, 6 Jan 1999 16:31:16 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think first of all that it's worth clarifying that *everyone" is in favour of persistence. No-one is advocating that policy should not be defined by the admin. The discussion is and should centre on how local policy is implemented, should it be done in the kernel or in userland. Those in favour of "non-persistence" are simply advocating that userland tools, such as scripts, be used to achieve persistence rather than having it built in to devfs itself. The arguments in favour of persistence of some form are largely won I think but I can go over them if people don't think so. I'd like to hear good arguments against putting persistence into the kernel since the userland solutions all have shortcomings that we're fighting to cludge around and will almost certainly need some kernel support in any case. I personally think that given that /dev becomes a kernel function creating /dev entries should also be a kernel function in their entirety and not simply in part. The only argument I can recall against a kernel implementation of policy is the need to maintain some form of device database. I don't see what the big deal is with this since it would have to exist in some form regardless of the implementation. My arguments against an userland implementation are largely based on security and robustness issues. >From a security point of view, unless policy is implemented at the time that the device is instantiated then a race condition exists between the creation of the dev entry and the application of the policy. The script solution is a non-starter since it takes no account of dynamically created devices after boot so I'll focus on my concerns for a daemon based solution. If devices are created with default perms (possibly based on class) then there is a clear race condition between the device coming into existence and the daemon running. This may or may not provide the potential for a security breach. To safeguard against this possibility the alternative is to create the device with 000 perms so that no possibility of a security hole exists. However, this creates a chicken/egg situation at boot since the root filesystem would need to be accessible by root or you're not going to get very far. To get around this you're going to have to have some form of kernel support for setting initial device perms or you won't be able to bring the machine up. This applies regardless of what solution you adopt for providing persistence of local policy. If you're going to have some mechanism in the kernel for specifying initial /dev perms at boot then why not just complete the implementation and make the kernel responsible for setting perms at other times. >From a robustness point of view, I'd be very concerned about relying on a userland process for maintaining /dev. If that daemon should not start or at some later point fall over then you may find you have a hard time getting a useable system. As a worst case scenario, should the on-disk copy of the image get damaged in any way then at next boot you'll have a totally screwed system, this is true of other binaries as well of course but I think we should minimise such dependencies not increase them. Personally, I can't see any way of preventing race conditions without applying policy when the device is created and that will require a kernel implementation of persistence. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 9 13:04:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA13778 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:04: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 NAA13770 for ; Sat, 9 Jan 1999 13:04: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 WAA05348 for ; Sat, 9 Jan 1999 22:04:16 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25054 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:04:15 +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 KAA19578 for ; Wed, 6 Jan 1999 10:46:06 -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 TAA25288 for ; Wed, 6 Jan 1999 19:45:36 +0100 (CET) To: freebsd-arch@FreeBSD.ORG Subject: Re: Implementing a DEVFS daemon In-reply-to: Your message of "Tue, 05 Jan 1999 04:56:44 PST." <199901051256.EAA65568@silvia.hip.berkeley.edu> Date: Wed, 06 Jan 1999 19:45:36 +0100 Message-ID: <25286.915648336@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Satoshi Asami writes: > Another hairy issue is how to keep the "easily editable ASCII" file > in a consistent state. Suppose the daemon and the editor (videvfs?) > need to lock the file before they make modifications. Now I edit > the configuration file [...] I think this can only be solved by using the classical "kill -1" strategy for rereading config files. But wait! It gets worse: If devd uses a plain chown(2) to apply the policy, [Upcall version:] devfs will notice that somebody changed a device owner and inform devd which will need to realize that this modification was one it did itself. [devd poll version:] devd will encounter the changed modes on the next scan and have to figure out that the change was not one done "by hand", but merely its own application of the policy. JMB said: > The timing issues seem to be ugly to me. It would be nice if > shutdown forced this daemon to roam over the /devfs tree. It almost > sounds like we need upcalls from the kernel to the daemon -- at > which point I wonder why the daemon is not in the kernel. I still > have to read 99% of the kernel, so if this is wacky tell me and I'll > shut up. Upcalls will be needed if we decide to tackle PnP/USB and so on, but belive me, it is still at lot less ugly than to implement the devd in the kernel. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Jan 9 13:12:00 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14517 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:12:00 -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 NAA14503 for ; Sat, 9 Jan 1999 13:11:57 -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 WAA05417 for ; Sat, 9 Jan 1999 22:11:21 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25128 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:11:21 +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 UAA24869 for ; Thu, 7 Jan 1999 20:04:44 -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 0zyT9d-0006AN-00; Thu, 7 Jan 1999 21:04:09 -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 VAA59743; Thu, 7 Jan 1999 21:02:35 -0700 (MST) Message-Id: <199901080402.VAA59743@harmony.village.org> To: Archie Cobbs Subject: Re: DEVFS, the time has come... Cc: arch@FreeBSD.ORG In-reply-to: Your message of "Thu, 07 Jan 1999 19:01:48 PST." <199901080301.TAA03996@bubba.whistle.com> References: <199901080301.TAA03996@bubba.whistle.com> Date: Thu, 07 Jan 1999 21:02:34 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901080301.TAA03996@bubba.whistle.com> Archie Cobbs writes: > In the case that no process has /dev/devfs open, devfs just does > it's normal "default" thing. I think that this is not desirable, but a mount option, as explained above (or my last message) would be preferable. If devfsd keeps dying, then if nothing else the user can remount /devfs with this option... I think it isn't desirable because it would allow devices to appear which local policy might otherwise want hidden, or only available in a chroot jail, etc. Or worse, if the devfsd dies for a chroot jail, undesirable devices may appear. 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 9 13:14:36 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14727 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:14: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 NAA14721 for ; Sat, 9 Jan 1999 13:14: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 WAA05431 for ; Sat, 9 Jan 1999 22:13:58 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25148 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:13:58 +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 TAA24079 for ; Thu, 7 Jan 1999 19:53:42 -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 0zySyv-0006AA-00; Thu, 7 Jan 1999 20:53:05 -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 UAA59709; Thu, 7 Jan 1999 20:51:31 -0700 (MST) Message-Id: <199901080351.UAA59709@harmony.village.org> X-To: Archie Cobbs To: arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Thu, 07 Jan 1999 19:01:48 PST." <199901080301.TAA03996@bubba.whistle.com> References: <199901080301.TAA03996@bubba.whistle.com> Date: Thu, 07 Jan 1999 20:51:30 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199901080301.TAA03996@bubba.whistle.com> Archie Cobbs writes: [[ devfsd and simple protocol ]] You could go one farther, although this might make devfsd mandatory, and have devfs tell devfsd a new device is available, and devfsd then tell devfs to create the device, complete with permissions, ownership, flags, etc. I don't think there would be a need for a NAK protocol. There would need to be some way of dealing with devfsd being killed and restarted (or crashing due to a bug). I'd imagine that new devices would queue up while devfsd was down. Actually, an arrangement like this wouldn't necessarily require devfsd. One could imagine a mount option that says effectively "go ahead and create devices" and another for default permissions if that would be useful. Then in an embedded environment you'd just have a shell script that would fire up on boot, doing whatever chmod you felt like with no need to have a daemon. Especially in a system where no devices can be added after poweron boot. In the running devfsd case, it would need to be run very very early in the boot process. I'd be worried about /dev/console not being present at all and init failing. I think that /dev/console is the only device that init needs to do its thing. If one were hack init, then one could have devfsd fork before init tried to open /dev/console. This would complicate things in the single user mode some what, so I'm not sure what the best approach would be here. Maybe for single user mode /devfs gets mounted in the no daemon mode, and then you get your prompt. Or maybe you'd need to mount it manually first (that seems more like the unix way to do that, come to think of it as not even / is mounted r/w in single user mode). 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 9 13:17:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA14953 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:17:14 -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 NAA14948 for ; Sat, 9 Jan 1999 13:17:12 -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 WAA05456 for ; Sat, 9 Jan 1999 22:16:40 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25195 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:16:39 +0100 (MET) Received: from whistle.com (s205m131.whistle.com [207.76.205.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA18914 for ; Thu, 7 Jan 1999 19:03:19 -0800 (PST) (envelope-from archie@whistle.com) Received: (from smap@localhost) by whistle.com (8.7.5/8.6.12) id TAA23138; Thu, 7 Jan 1999 19:02:16 -0800 (PST) Received: from bubba.whistle.com( 207.76.205.7) by whistle.com via smap (V2.0) id xma023134; Thu, 7 Jan 99 19:01:49 -0800 Received: (from archie@localhost) by bubba.whistle.com (8.8.7/8.6.12) id TAA03996; Thu, 7 Jan 1999 19:01:48 -0800 (PST) From: Archie Cobbs Message-Id: <199901080301.TAA03996@bubba.whistle.com> Subject: Re: DEVFS, the time has come... In-Reply-To: <199901051823.LAA13960@harmony.village.org> from Warner Losh at "Jan 5, 99 11:23:29 am" X-To: imp@village.org (Warner Losh) To: arch@FreeBSD.ORG Date: Thu, 7 Jan 1999 19:01:48 -0800 (PST) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Warner Losh writes: > To recap the design for devfsd and what it requires of devfs: > (1) devfsd will start by chmod/chown/chgrp the nodes it finds in > its database. Otherwise it will exec a default script > with one arg to get the node to have the right > permissions. > (2) devfsd will wakeup when a poll fires.[*] > (3) devfsd will scan the tree, doing its thing ala startup, > skipping those nodes that aren't new or changed. > > (1) devfs will honor chown, chgrp, chmod, symbolic links and > mkdir. > (2) devfs will cause the poll to fire[*] when one of these events > happens. > > Nothing else. No sysctls are used. No device classes are needed (but > could be implemented if someone wanted to do so). That sounds good to me. If routed talks to the kernel via the routing socket, and syslogd listens to the kernel via the syslog device.. then in the same way, devfsd could talk to the kernel via /dev/devfs (or whatever, that's an implementation detail). Then we just need to design the (hopefully very simple) protocol. To avoid the security race window of having a device appear with default permissions for a while before devfsd can get around to chmod'ing it, devfs could query devfsd via this /dev/devfs connection for the initial permissions before creating the directory entry, etc. Other tricks useful in a chroot() jail could be done, e.g., devfsd tells devfs to *not* create an entry for a newly inserted PC card so the chroot() prisoner can't access it, etc. In the case that no process has /dev/devfs open, devfs just does it's normal "default" thing. I'm very glad we all agree that persistence should be handled *out* of the kernel :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.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 9 13:53:25 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA20147 for freebsd-arch-outgoing; Sat, 9 Jan 1999 13:53:25 -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 NAA20141 for ; Sat, 9 Jan 1999 13:53:22 -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 WAA05845 for ; Sat, 9 Jan 1999 22:52:47 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA25558 for freebsd-arch@freebsd.org; Sat, 9 Jan 1999 22:52:46 +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 NAA18519 for ; Sat, 9 Jan 1999 13:37:29 -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 WAA18015; Sat, 9 Jan 1999 22:36:49 +0100 (CET) X-To: Paul Richards To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Wed, 06 Jan 1999 16:31:16 GMT." Date: Sat, 09 Jan 1999 22:36:49 +0100 Message-ID: <18013.915917809@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Paul Richards writes: > I think first of all that it's worth clarifying that *everyone" is > in favour of persistence. No-one is advocating that policy should > not be defined by the admin. Clearly you're not even trying to use the same terminology as us here. No, there is not unanimous support for persistence ( which means that a random "chmod 654 /dev/foo" is persistent forever) There >IS< agreement that security must not be worse and that the admin should be left in control. > The discussion is and should centre on how local policy is > implemented, should it be done in the kernel or in userland. It is also obvious that you're not reading the thread either. Persistence can be done in a daemon, probably better and certainly less error prone than in the kernel. Consequently the kernel part will be just the bare bones needed, and everything else (policy or persistence or both) will be done in a device-daemon. > I'd like to hear good arguments against putting persistence into the > kernel since the userland solutions all have shortcomings that we're > fighting to cludge around and will almost certainly need some kernel > support in any case. 1. It can be done in userland, there is no performance requirement to put it in the kernel. 2. You can't do it without a lot of kludging around in the kernel either. 3. PicoBSD and other groups of people want small kernels. 4. Doing it in a daemon makes it possible for people to choose what they want. (you obviously don't want persistence on a chroot partition.) Paul: please read the entire thread before you jump in. Your applicable comments will be most welcome. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message