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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
