From owner-freebsd-arch Sun Jan 10 16:42:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA07315 for freebsd-arch-outgoing; Sun, 10 Jan 1999 16:42:24 -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 QAA07309 for ; Sun, 10 Jan 1999 16:42:21 -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 BAA04119 for ; Mon, 11 Jan 1999 01:41:44 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id BAA42734 for freebsd-arch@freebsd.org; Mon, 11 Jan 1999 01:41:44 +0100 (MET) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA18753 for ; Sat, 9 Jan 1999 13:40:31 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.1/8.9.1) with ESMTP id OAA20702; Sat, 9 Jan 1999 14:39:57 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199901092139.OAA20702@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 X-To: Paul Richards To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... In-reply-to: Your message of "Wed, 06 Jan 1999 16:31:16 GMT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Jan 1999 14:31:50 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I'll focus on my concerns for a daemon based solution. ... > If devices are created with default perms (possibly based on class) > then there is a clear race condition between the device coming into > existence and the daemon running. This may or may not provide the > potential for a security breach. To safeguard against this > possibility the alternative is to create the device with 000 perms > so that no possibility of a security hole exists. However, this > creates a chicken/egg situation at boot since the root filesystem > would need to be accessible by root or you're not going to get very > far. Permissions are not a problem: Script started on Sat Jan 9 14:10:19 1999 You have mail. # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s2a 31743 26514 2690 91% / /dev/da0s2e 98479 28280 62321 31% /var /dev/da0s2f 695311 543183 96504 85% /usr /dev/da0s2g 1849623 1673301 28353 98% /a procfs 4 4 0 100% /proc /dev/da1s1a 4425736 1279448 2792232 31% /c # umount /c # chmod 000 /dev/da1s1a # ls -l /dev/da1s1a b--------- 1 root wheel 4, 0x00020008 Sep 4 1997 /dev/da1s1a # mount /c # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0s2a 31743 26514 2690 91% / /dev/da0s2e 98479 28280 62321 31% /var /dev/da0s2f 695311 543183 96504 85% /usr /dev/da0s2g 1849623 1673301 28353 98% /a procfs 4 4 0 100% /proc /dev/da1s1a 4425736 1279448 2792232 31% /c # exit Script done on Sat Jan 9 14:10:44 1999 There is a chicken and egg problem with DEVFS and mounting root that Julian alluded to some time back having to do, I believe, with needing access to DEVFS before root is mounted, but this is a solvable problem. If you agree that creating the nodes 000 and possibly even in the whiteout state is sufficient to safeguard the system, then there is no exploitable race. > From a robustness point of view, I'd be very concerned about > relying on a userland process for maintaining /dev. If that daemon > should not start or at some later point fall over then you may find > you have a hard time getting a useable system. If the daemon doesn't start, you'll find yourself in single user mode and can use chmod/chown to manually arrive at a usable system. If the daemon dies after performing initial configuration, the worst case scenario is that persistence of chown/chgrp/etc. operations will be lost with a reboot and that you will have to perform manual operations for non-root users to see dynamic devices that have arrived after devd's death. This does not seem unacceptable for a pathological situation. > As a worst case scenario, should the on-disk copy of the image get > damaged in any way then at next boot you'll have a totally screwed > system, this is true of other binaries as well of course but I think > we should minimise such dependencies not increase them. If we become really worried about these recovery scenarios, we can ship a modified MAKEDEV that can be run to provide standard permissions on extant nodes. This should make it quite easy to get the system up far enough to restore or rebuild a working binary. > Personally, I can't see any way of preventing race conditions > without applying policy when the device is created and that will > require a kernel implementation of persistence. Before attempting to push a kernel implementation, please define the kinds of persistent information that can be recorded. How much kernel bloat will it take to be able to specify policy for ranges of non-existent devices and how do you specify this policy? I would want the full flexibility of regular expression matching to specify policy for dynamic devices. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message