Date: Mon, 20 Sep 1999 16:35:47 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: "Matthew N. Dodd" <winter@jurai.net>, Chuck Robey <chuckr@mat.net>, Wayne Cuddy <wayne@crb-web.com>, FreeBSD Hackers List <freebsd-hackers@FreeBSD.ORG> Subject: Re: what is devfs? Message-ID: <Pine.BSF.3.95.990920163316.6478C-100000@current1.whistle.com> In-Reply-To: <19990920160107.33337@hydrogen.fircrest.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Sep 1999, John-Mark Gurney wrote: > 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... While I sharply disagree, with your assertion, I also point out that if you make such a all-singing-all-dancing devfsd, then you might as well get rid of devfs entirely, and just have devfsd make the devices using normal mknod commands. > > -- > 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?Pine.BSF.3.95.990920163316.6478C-100000>