From owner-freebsd-arch Tue Jan 5 16:22:33 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA10403 for freebsd-arch-outgoing; Tue, 5 Jan 1999 16:22:33 -0800 (PST) (envelope-from owner-freebsd-arch@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA10398 for ; Tue, 5 Jan 1999 16:22:31 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.1a/8.9.1) with ESMTP id BAA24111 for ; Wed, 6 Jan 1999 01:22:03 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA23724 for freebsd-arch@freebsd.org; Wed, 6 Jan 1999 01:22:03 +0100 (MET) Received: from vader.cs.berkeley.edu (vader.CS.Berkeley.EDU [128.32.38.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA12439; Tue, 5 Jan 1999 04:57:14 -0800 (PST) (envelope-from asami@vader.cs.berkeley.edu) Received: from silvia.hip.berkeley.edu (sji-ca7-163.ix.netcom.com [209.109.235.163]) by vader.cs.berkeley.edu (8.8.7/8.7.3) with ESMTP id EAA08161; Tue, 5 Jan 1999 04:56:47 -0800 (PST) Received: (from asami@localhost) by silvia.hip.berkeley.edu (8.9.1/8.6.9) id EAA65568; Tue, 5 Jan 1999 04:56:44 -0800 (PST) Date: Tue, 5 Jan 1999 04:56:44 -0800 (PST) Message-Id: <199901051256.EAA65568@silvia.hip.berkeley.edu> To: jmb@FreeBSD.ORG CC: freebsd-arch@FreeBSD.ORG In-reply-to: <199901040055.QAA02594@hub.freebsd.org> (jmb@FreeBSD.ORG) Subject: Re: Implementing a DEVFS daemon From: asami@FreeBSD.ORG (Satoshi Asami) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > From: "Jonathan M. Bresler" > > 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