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