From owner-freebsd-arch Wed Nov 28 12:26: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from wellington.cnchost.com (wellington.concentric.net [207.155.252.14]) by hub.freebsd.org (Postfix) with ESMTP id 6485037B405 for ; Wed, 28 Nov 2001 12:25:51 -0800 (PST) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by wellington.cnchost.com id PAA03173; Wed, 28 Nov 2001 15:25:39 -0500 (EST) [ConcentricHost SMTP Relay 1.14] Message-ID: <200111282025.PAA03173@wellington.cnchost.com> To: Poul-Henning Kamp Cc: mjacob@feral.com, arch@FreeBSD.ORG Subject: Re: Anybody working on devd? In-reply-to: Your message of "Wed, 28 Nov 2001 19:41:35 +0100." <38091.1006972895@critter.freebsd.dk> Date: Wed, 28 Nov 2001 12:25:38 -0800 From: Bakul Shah Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > >There's a race between some joblow driver setting completely loose permissions > >and devd setting the policy based ones. This is a security hole. This is what > >I meant by "either you trust the driver or you don't". The consensus here is > >that "we don't". > > > >Therefore, internally make_dev uses 0/0 600 as default- not settable by > >driver. The default policy for picobsd would be 666 I assume. > > Guys, > > Witht rules system I'm proposing you can have "any of the above" > if you want. > > No matter which single one we choose, it is inadequate for one or > more of the other cases. > > It needs to be possible to specify a policy and the default policy > if you don't do that need to be sensible. > > If anyone has a better suggestion how to express the policy than > by sticking rules like I proposed into the kernel from a userland > program, I'm all ears... May be device nodes should be created by a user process, not any kernel entity, so that the process can implement any policy it wants. This is what we did 20 years back (at Fortune Systems) and I still prefer it. A syscall queried each device driver which returned a list of supported canonical device names and major+minor for each (IIRC, a printf string like "tty%d" and a range of acceptable numbers). A user program run at boot time created the actual indoes, create links (e.g. cuaa0 for ttyd0), etc. Back then devices only appeared at boot time so this was good enough. Now I'd probably create a notification facility accessed via a socket or something (like the one for route add/change/deletes). A daemon (devd?) can be notified of appearance/disappearance events of devices and create/delete appropriate device nodes as well as perform any auxiliary actions such as automounting/dismounting. I believe such a daemon can be taught to create the right nodes for any jail (and no it doesn't have to run in one) assuming it is told where each jail's devices live. You can also start devd in a jail if you wish since any number of processes can listen for device events. At my last company we needed something similar -- depending on which io cards were plugged in the router we needed to create different kinds of and number of network interfaces (the actual numbers were far higher than your typical freebsd system). We then needed to download firmware on certain boards + we wanted each properly working interface to be automatically configured in a particular way. We also needed to `watch' all IO cards, power supplies, fans and backplanes to handle any failure and apply appropriate switch over. We certainly did not want the kernel to directly deal with all this mess. Even the daemon watching device events did not do it all -- it called on other programs as necessary. So I think a user level devd + a device change notification scheme makes a lot of sense compared to sticking policy in the kernel. FWIW. -- bakul To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message