Date: Tue, 5 Jan 1999 04:56:44 -0800 (PST) From: asami@FreeBSD.ORG (Satoshi Asami) To: jmb@FreeBSD.ORG Cc: freebsd-arch@FreeBSD.ORG Subject: Re: Implementing a DEVFS daemon Message-ID: <199901051256.EAA65568@silvia.hip.berkeley.edu> In-Reply-To: <199901040055.QAA02594@hub.freebsd.org> (jmb@FreeBSD.ORG)
next in thread | previous in thread | raw e-mail | index | archive | help
> From: "Jonathan M. Bresler" <jmb@FreeBSD.ORG> > > The timing issues seem to be ugly to me. It would be nice if shutdown Yes. There could also be a potential security hole where people could take advantage of the time lag between the device appearance and this daemon changing its permissions. [This is not a problem if the devices arrive with 'suitable' permissions; ie, totally restricted. -EE] > forced this daemon to roam over the /devfs tree. It almost sounds > like we need upcalls from the kernel to the daemon -- at which point > I wonder why the daemon is not in the kernel. I still have to read > 99% of the kernel, so if this is wacky tell me and I'll shut up. Another hairy issue is how to keep the "easily editable ASCII" file in a consistent state. Suppose the daemon and the editor (videvfs?) need to lock the file before they make modifications. Now I edit the configuration file. While I'm editing it, the daemon is waiting, and when I finish, the daemon wakes up and tries to merge its changes. What if there is a merge conflict? What if I edited the file wrong and there is a syntax error? And if I hold the file too long for editing, there could be security implications too (see above). At which point I wonder why this is not done using pure filesystem semantics (chmod, chown, etc.). :) [chown/chmod is difficult to use to express policies, especially for devices that are not yet present. -EE] Satoshi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901051256.EAA65568>