From owner-freebsd-hackers Wed Apr 19 12:03:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA26320 for hackers-outgoing; Wed, 19 Apr 1995 12:03:25 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id MAA26314 for ; Wed, 19 Apr 1995 12:03:24 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id MAA09677; Wed, 19 Apr 1995 12:03:12 -0700 From: Poul-Henning Kamp Message-Id: <199504191903.MAA09677@ref.tfs.com> Subject: Re: DEVFS ownership and permissions To: dufault@hda.com (Peter Dufault) Date: Wed, 19 Apr 1995 12:03:11 -0700 (PDT) Cc: terry@cs.weber.edu, hackers@freefall.cdrom.com In-Reply-To: <199504191859.OAA05945@hda.com> from "Peter Dufault" at Apr 19, 95 02:59:42 pm Content-Type: text Content-Length: 1061 Sender: hackers-owner@FreeBSD.org Precedence: bulk > > I believe we will make it part of the boot procedure to have a shell > > script set the permissions. > > That is kind of klunky. How about a utility that snapshots the > permissions and reestablishes them at boot up? You could try to run it > at a clean shutdown if we ever get beyond a "10 seconds before you're dead" > shutdown. So that any holes made by users will persist over boot-up ? Hmm, seems like an unusual request to me :-) > > Permissions are policy, and policy does not belong in the kernel. > > Site policy doesn't belong in the kernel. Other policy does, which > is why I think I prefer a devfs versus a symlink approach of establishing > aliases for the "shallow" (/dev/*) device names. I'm being wimpy > because I haven't thought about this much yet. Well, devfs will be hashed out in several rounds, so don't worry you will have plenty of time... -- Poul-Henning Kamp -- TRW Financial Systems, Inc. 'All relevant people are pertinent' && 'All rude people are impertinent' => 'no rude people are relevant'