From owner-freebsd-current Fri Feb 9 12:13:21 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA06893 for current-outgoing; Fri, 9 Feb 1996 12:13:21 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id MAA06888 for ; Fri, 9 Feb 1996 12:13:18 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA11001; Fri, 9 Feb 1996 13:07:38 -0700 From: Terry Lambert Message-Id: <199602092007.NAA11001@phaeton.artisoft.com> Subject: Re: FS PATCHES: THE NEXT GENERATION To: roberto@keltia.freenix.fr (Ollivier Robert) Date: Fri, 9 Feb 1996 13:07:38 -0700 (MST) Cc: phk@critter.tfs.com, jkh@time.cdrom.com, julian@ref.tfs.com, terry@lambert.org, current@freebsd.org In-Reply-To: <199602091822.TAA28694@keltia.freenix.fr> from "Ollivier Robert" at Feb 9, 96 07:22:38 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org Precedence: bulk > It seems that Poul-Henning Kamp said: > > I want to be able to define a policy for permissions in /dev, and no > > form is more unix-like and suitable than > > > > chmod 644 tty* > > chown root.dev disk/* > > We could use something analog to the mtree description files for /devs > entries... And you could "save" the current settings to the database in an "rc.shutdown" or some similar method. Or by making a daemon that makes a "get event" call to the devfs and returns on each chmod, etc. and makes the change immediately, in case you don't shut down cleanly. The point is, that this is a solvable problem, and you don't need to delay devfs deployment until after it is solved just because someone might want to someday need the soloution for some bogus legacy app. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.