From owner-freebsd-hackers Wed Apr 19 12:17:27 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA26575 for hackers-outgoing; Wed, 19 Apr 1995 12:17:27 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA26569 for ; Wed, 19 Apr 1995 12:17:26 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19689; Wed, 19 Apr 95 13:10:57 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9504191910.AA19689@cs.weber.edu> Subject: Re: DEVFS ownership and permissions To: phk@ref.tfs.com (Poul-Henning Kamp) Date: Wed, 19 Apr 95 13:10:57 MDT Cc: dufault@hda.com, hackers@freefall.cdrom.com In-Reply-To: <199504191846.LAA09577@ref.tfs.com> from "Poul-Henning Kamp" at Apr 19, 95 11:46:08 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@FreeBSD.org Precedence: bulk > Contrary to to Terry, I have talked with Julian about his ideas :-) > > I belive we will make it part of the boot procedure to have a shell > script set the permissions. > > Permissions are policy, and policy does not belong in the kernel. Without rserving part of the name space for uid/gid or permissions, you can't have a non-initialized default state for these values. I've already noted that an rc style mechanism would be necessary for permissions not equal to the default. A devfs is not magic; Julian, me, and god knows who else have discussed the idea to death at 3 or 4 seperate occasions in the past. It's not likely that we would have different opinions in anything but implementation details this late in the game, especially since it's a given that Julian has already implemented the thing -- several times -- I have an older copy on hand, actually. 8-). Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.