From owner-freebsd-current Tue Jul 16 18:52:25 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D44AF37B400 for ; Tue, 16 Jul 2002 18:52:22 -0700 (PDT) Received: from turbine.trit.org (turbine.trit.org [63.198.170.141]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54EEC43E3B for ; Tue, 16 Jul 2002 18:52:22 -0700 (PDT) (envelope-from dima@trit.org) Received: from turbine.trit.org (localhost [127.0.0.1]) by turbine.trit.org (Postfix) with ESMTP id 30D953E22 for ; Wed, 17 Jul 2002 01:52:21 +0000 (UTC) To: current@freebsd.org Subject: DEVFS rule subsystem (was: cvs commit: src/sbin Makefile src/sbin/devfs Makefile devfs.8 devfs.c extern.h rule.c src/sys/conf files src/sys/fs/devfs devfs.h devfs_devs.c devfs_rule.c devfs_vfsops.c devfs_vnops.c ) In-Reply-To: <200207170146.g6H1kpWl024662@freefall.freebsd.org>; from dd@FreeBSD.org on "Tue, 16 Jul 2002 18:46:51 -0700 (PDT)" Date: Wed, 17 Jul 2002 01:52:21 +0000 From: Dima Dorfman Message-Id: <20020717015221.30D953E22@turbine.trit.org> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I wrote: > Log: > Introduce the DEVFS "rule" subsystem. DEVFS rules permit the > administrator to define certain properties of new devfs nodes before > they become visible to the userland. Both static (e.g., /dev/speaker) > and dynamic (e.g., /dev/bpf*, some removable devices) nodes are > supported. Each DEVFS mount may have a different ruleset assigned to > it, permitting different policies to be implemented for things like > jails. This isn't entirely complete (e.g., globbing isn't implemented), but I think it works well enough for most purposes. I would appreciate it if people would try it and see whether it does what they want it to do (especially all of those people that have been asking for something like this since DEVFS became standard!). The devfs(8) manual page is a pretty good reference of the existing features and semantics, but it lacks polish needed to be able to serve as an introduction. As a starting point, try the following (you need to be root to do this stuff, of course): devfs rule -s 10 add path 'bpf*' group wheel mode 660 devfs ruleset 10 This should permit users in the "wheel" group to use the bpf devices (generally this probably isn't a good idea, but it's a good example, and easy to test). To test it, just run tcpdump as a non-root user in wheel; it should work unless you already have bpf devices with old permissions (rules are applied when the node is created (make_dev(9)), or if explicitly requested); in that case, you can do: devfs rule applyset to make your rules take effect on all current nodes. Some things to note about the above (this is all described in devfs(8)): if a mount-point isn't specified, /dev is assumed; if a ruleset isn't explicitly specified (command 3), the one associated with the mount-point you're using is assumed; globbing for the "path" argument isn't working yet (only a trailing asterisk is supported right now). At the moment, I'm not sure where people should be putting "devfs" commands to be run at boot time. I think hijacking /etc/rc.devfs for this purpose (a la rc.firewall) is probably the best idea, but if some of the rc hackers have better ideas, please let us (me) know. Questions and comments are most welcome. In particular, if you use this with removable devices (e.g., USB), I'd like to hear about it. I haven't had much of an opportunity to test this with different removable devices, and I'd like to know how well it works in such an environment. Thanks, Dima. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message