From owner-freebsd-arch Fri Jan 1 19:17:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA00263 for freebsd-arch-outgoing; Fri, 1 Jan 1999 19:17:33 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA00250 for ; Fri, 1 Jan 1999 19:17:30 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id EAA05085 for ; Sat, 2 Jan 1999 04:17:07 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id EAA93496 for freebsd-arch@freebsd.org; Sat, 2 Jan 1999 04:17:07 +0100 (MET) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA29882 for ; Fri, 1 Jan 1999 19:15:15 -0800 (PST) (envelope-from imp@village.org) Received: from harmony [10.0.0.6] by rover.village.org with esmtp (Exim 1.71 #1) id 0zwHWS-0001IQ-00; Fri, 1 Jan 1999 20:14:40 -0700 Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.1/8.8.3) with ESMTP id UAA09044; Fri, 1 Jan 1999 20:12:52 -0700 (MST) Message-Id: <199901020312.UAA09044@harmony.village.org> To: Mike Smith Subject: Re: DEVFS, the time has come... Cc: freebsd-arch@FreeBSD.ORG In-reply-to: Your message of "Fri, 01 Jan 1999 17:16:09 PST." <199901020116.RAA03885@dingo.cdrom.com> References: <199901020116.RAA03885@dingo.cdrom.com> Date: Fri, 01 Jan 1999 20:12:52 -0700 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG What we absolutely must not do is to create devices that will cause the security of the system to be compromised. This would be absolutely disasterous from a PR point of view. In message <199901020116.RAA03885@dingo.cdrom.com> Mike Smith writes: > Personally, I think a persistent DEVFS would be "better" than a > non-persistent DEVFS. But it's been quite clear for some time that > persistence is something that can be built onto a working DEVFS, so a > non-persistent DEVFS is something that we definitely want to start with. I think this is a good bottom line. Even if we had good documentation, I think it will still violate POLA. We must remember that rc.* is not an acceptible solution because devices can come and go. If my mouse were plugged into a USB port, and I unplugged it then plugged it back in, the device would go away and come back. If I chmod'd it on boot, those setting would be lost. Or if I forgot to have my mouse plugged in on boot and plugged it in after the rc scripts had run. The system still should allow access to that mouse, but only to the person that is on the console. We'd likely get lots of complaints if we violate POLA where removable devices are concerned. I know it is a huge PITA to do persistance correctly, and that people have fought doing it for years. However, I think that you need some level of persistance in order to deal with what will become an increasing common problem. Warner [The problem of insecure device-creations can be solved by defaulting to not create devices dynamically after boot. -EE] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message