Date: Sat, 2 Jan 1999 23:25:13 -0700 From: Nate Williams <nate@mt.sri.com> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901030625.XAA18116@mt.sri.com> In-Reply-To: <6040.915273405@critter.freebsd.dk> References: <Pine.BSF.4.05.9901011829540.335-100000@picnic.mat.net> <6040.915273405@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901030625.XAA18116>