From owner-freebsd-current Tue Nov 19 0:36: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EF6F37B401 for ; Tue, 19 Nov 2002 00:36:08 -0800 (PST) Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB8C43E77 for ; Tue, 19 Nov 2002 00:36:07 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0120.cvx21-bradley.dialup.earthlink.net ([209.179.192.120] helo=mindspring.com) by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18E3rW-0000o9-00; Tue, 19 Nov 2002 00:36:02 -0800 Message-ID: <3DD9F777.2502F3F0@mindspring.com> Date: Tue, 19 Nov 2002 00:33:59 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: kip@eventdriven.org Cc: Bruce Evans , Kris Kennaway , current@FreeBSD.ORG Subject: Re: Device permissions with DEVFS References: <20021119081649.13088.qmail@web14008.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Kip Macy wrote: > Sorry, if I'm repeating something already said, but > the tone of your mail would indicate that I'm not. > > This doesn't sound like an intrinsic limitation of > devfs, just an issue with how it is structured now. > There should just be a central file for all the > devices which devfs sucks in at build (or maybe boot) > time specifying the appropriate permissions and any > other configuration information. A separate ELF data section for this information would allow kernel modules to have this information edited with a tool, as well permitting the kernel itself to be edited with the same tool, so that site defaults could be persistantly changed from the source tree defaults. Indeed, this would allow the permissions to be listed in the case that Bruce was complaining about, which is the inability to see what will happen when the hardware is present, if it's not available to the tester. An extension of this would permit chmod's against the devfs to be "written back" to the kernel or driver module affected, assuming your secure level is low enough and your flags are set to permit it, which also gets rid of the common complaint about persistance (which is really just a handy thing to use to bitch about devfs when you can't come up with any legitimate complaints, IMO). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message