From owner-freebsd-hackers Mon Sep 20 16: 3:24 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from mg-20425418-51.ricochet.net (mg-20425427-42.ricochet.net [204.254.27.42])
by hub.freebsd.org (Postfix) with ESMTP id A4A6315D18
for <freebsd-hackers@FreeBSD.ORG>; Mon, 20 Sep 1999 16:03:07 -0700 (PDT)
(envelope-from gurney_j@efn.org)
Received: (from jmg@localhost)
by mg-20425418-51.ricochet.net (8.9.1/8.8.7) id QAA14056;
Mon, 20 Sep 1999 16:02:05 -0700 (PDT)
Message-ID: <19990920160107.33337@hydrogen.fircrest.net>
Date: Mon, 20 Sep 1999 16:01:07 -0700
From: John-Mark Gurney <gurney_j@efn.org>
To: "Matthew N. Dodd" <winter@jurai.net>
Cc: Chuck Robey <chuckr@mat.net>,
Julian Elischer <julian@whistle.com>,
Wayne Cuddy <wayne@crb-web.com>,
FreeBSD Hackers List <freebsd-hackers@FreeBSD.ORG>
Subject: Re: what is devfs?
References: <Pine.BSF.4.10.9909191854230.4696-100000@picnic.mat.net> <Pine.BSF.4.10.9909200218000.20959-100000@sasami.jurai.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <Pine.BSF.4.10.9909200218000.20959-100000@sasami.jurai.net>; from Matthew N. Dodd on Mon, Sep 20, 1999 at 02:20:06AM -0400
Reply-To: John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Organization: Cu Networking
X-Operating-System: FreeBSD 3.0-RELEASE i386
X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4
X-Files: The truth is out there
X-URL: http://resnet.uoregon.edu/~gurney_j/
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG
Matthew N. Dodd scribbled this message on Sep 20:
> On Sun, 19 Sep 1999, Chuck Robey wrote:
> > But it was to the subject on the Subject: line, Julian. We know what side
> > you're on, but there are 2 sides to the argument. Isn't there some way
> > that it can be set up to *optionally* have permission persistence?
>
> Seems like a devfsd using the file monitoring hooks would work; you'd only
> update the persistent store if you were running devfsd. devfsd would read
> the store and init /dev with the contents. I think the only issue that
> would involve thinking would be whiteouts (and the actual devfsd code of
> course.)
one thing that HAS to happen is the fast that some devices CAN'T "appeare"
until the devfsd says it can, unless we force a very restrictive permision
on all devices (600 or something similar) otherwise we will have security
wholes up the wazoo... don't forget about this... a devfsd daemon is
definately the way to go...
--
John-Mark Gurney Voice: +1 408 975 9651
Cu Networking
"The soul contains in itself the event that shall presently befall it.
The event is only the actualizing of its thought." -- Ralph Waldo Emerson
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message