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? Message-ID: <19990920160107.33337@hydrogen.fircrest.net> 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 References: <Pine.BSF.4.10.9909191854230.4696-100000@picnic.mat.net> <Pine.BSF.4.10.9909200218000.20959-100000@sasami.jurai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990920160107.33337>