Date: Sat, 02 Jan 1999 14:35:03 +0800 From: Peter Wemm <peter@netplex.com.au> To: freebsd-arch@FreeBSD.ORG Subject: Re: DEVFS, the time has come... Message-ID: <199901020635.OAA03578@spinner.netplex.com.au> In-Reply-To: Your message of "Fri, 01 Jan 1999 20:55:55 PST." <199901020455.UAA01211@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: [..] > > > If my mouse were plugged into a USB port, > > > and I unplugged it then plugged it back in, the device would go away > > > and come back. If I chmod'd it on boot, those setting would be lost. > > > > I hope this isn't lost in the noise. Any 'boot' configuration is a loss > > for the (hopefully soon to be coming) 'dynamic' scheme that keeps > > getting talked about. Devices will come and go, and any scheme that > > doesn't take this into account will be a net loss. > > I was just discussing this with Eivind; I think that we can comfortably > cover every set of requirements with: > > - a kernel-wide default owner/group/permissions for new nodes, which > can be overridden by the device driver in response to eg. > configuration arguments or device-specific concerns. > - a mount option which determines whether new nodes show up in the > devfs instance. The way I imagine this would work (in a non-persistant devfs), would be that there would be some predefined device node permission classes that would set the default for devices of that type where there is likely to be changes in bulk depending on the role of the machine. For example, there might be a node for tty, pty, callout (modem) devices, tape, disk, sound, mouse (non-tty), and a default (0700, root, wheel). When a "new" device appears (including at boot), it would bind itself to the appropriate class, if it was appropriate. The key thing would be that the node would shadow the permissions of the class node until it was given explicit permissions of it's own. Suppose the class nodes were visible in sysctl. If somebody did this: sysctl -w vfs.devfs.class.tape.mode=0666 Then all the nodes that were attached would simultaniously change from the original (presumably 0600) to 0666. However, if /dev/rsa0 had previously been chmodded to 0660, it would have left the class and would not be affected by this change. This could cover problems like 'which uid is uucp'? At boot time, the rc scripts could set the vfs.devfs.class.<foo>.uid=66 and the devfs would take shape. The advantage of this is that uids do not need to be encoded in the kernel, and it's relatively simple to tighten up or relax permissions on a large scale without having to resort to chmod/chown etc. This could be implemented by each node's control struct having a uid/gid/ mode field, and a pointer to a default node. If the default pointer was set, the local uid/gid/mode would be ignored, and VOP_GETATTR/VOP_ACCESS etc would pick up the permissions from the parent. This means that changing the sysctl wouldn't mean that devfs would have to sweep the node tree at all, since the permissions are looked up at access time. Device drivers only then would need minimal (or no) permission information. When attaching to the devfs, it may choose to nominate that "this is a pty" and the devfs will connect it under the pty default modes. If the driver doesn't specify at all, then it's a "default". Other nice things could be done would be magic self resetting permissions on last close (based on class), secure pty allocation and handoff (When the cloning pty master is opened, the slave appears with the same uid as the opener, mode 620, gid tty, all ready for the client to grab), etc. Re loosing nodes... Would 'mount -u -o reload /dev' cut it? Re chroot jails.. Would mounting an instance, cleaning it out and then doing a 'mount -u -r /my/chroot/jail/dev' cut it? (making it readonly would prevent changes, devices appearing, etc.) Yes, we need a devfs. Yes, it should be on by default. I prefer non-persistance, especially if measures are taken to make it easier to cope with. I would prefer to not have to put policy into drivers, but some will be unavoidable - /dev/null for example. Perhaps classifying nodes and having a group of settings might do the trick. Cheers, -Peter -- Peter Wemm <peter@netplex.com.au> Netplex Consulting "No coffee, No workee!" :-) 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?199901020635.OAA03578>