Date: Mon, 16 Feb 1998 11:26:50 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Mike Smith <mike@smith.net.au> Cc: "Justin T. Gibbs" <gibbs@plutotech.com>, "John S. Dyson" <toor@dyson.iquest.net>, bde@zeta.org.au (Bruce Evans), dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence Message-ID: <199802161829.LAA19996@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 16 Feb 1998 03:56:16 PST." <199802161156.DAA06121@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >I think that one file per node is wasteful and inefficient. It also >> >fails to provide for prototype entries, as phk raised yesterday. >> >> There is no "prototype mechanism" in the way the system currently works and >> I don't perceive a large need for this functionality. > >There is, and a number of other people do. > >The prototype mechanism in the current system is implemented in >the /dev/MAKEDEV script. DEVFS as it currently stands moves this >prototyping into the kernel, and makes it nonconfigurable. And most people never modify /dev/MAKEDEV. Instead, they simply chmod/ chown devices after they are created by MAKEDEV. In a DEVFS scenario, you have the same capabilities. >This is not good from the point of view of a system where device node >arrival is possible and nodes might arrive in an insecure state. And, with the option of only allowing devices with backing store, you prevent unexpected new device arrival from causing a security problem. I would also argue that a "secure" system would not have any device arrivals (other than newly allocated ptys perhaps) during normal operation, and the arrivals that do occur during maintenance periods would be fully known to the machines operators (a replacement disk drive, bringing the tape drive on line, etc). >> login.access already >> deals with most of the compelling cases where this functionality might be >> beneficial. > >How so? Login.access controls login sources, it appears to have >nothing for generally handling permissions on arbitrary sets of device >nodes. I meant /etc/fbtab. >> Going to a single file format increases the complexity of the >> "parser" in the kernel... > >True. But it need not be overcomplex. > >> I mean are you going to handle reg-exps in your >> prototypes? > >Given the typical format of a device node's name, that's hardly likely. n?e?r?st[0-9]+ and that's not even really complete (control devices, sub mode devices, etc). >> Can you ensure that your parser will not crash the kernel for >> all input? > >Can you gurarantee that the kernel will not crash for all input? Most (all?) areas of the kernel never directly interpret user produced data. Sure, the kernel moves user data, copies it, sends it to a device, etc, but the kernel is not currently prone to the typical buffer overflows and other attacks that you usually see in userland provided services. >> If you put the parser in "mount_devfs" (ala IPFW), you still >> have to come up with a clean, space efficient way to represent these >> prototypes since "arrival events" are bound to happen after the initial >> mount. > >As are rule arrivals. As Julian and I discussed, the interface is >likely to be via a file-like object in the mounted devfs having similar >semantics to the file beneath when the devfs is not mounted. Sounds much more complicated and space consumptive than it has to be. >> A file per node means that parsing is essentially a namei/stat/check >> operation. > >It also means that duplicating the node permissions into a new >mountpoint requires replication of all of the nodes, and backup >requires archiving them all. When would you be duplicating the node permissions into a new mountpoint? If you are doing this, what are the rules for reconciling permissions with those that already exist in the target mount point? A backup of the underlying mount point should handle back ups in either scenario and the "multi-file" approach is no different than the backup situation we have now for mknoded files. >> No allocated space for mount time rules is required since the >> kernel can easily "check a rule" at any time. When new nodes "arrive" >> for the first time, their default permissions should be on the secure side. > >... and then they can't be used until they are *manually* fixed up. I would say that 99.99% of our user community never modifies the permissions from the default that MAKEDEV creates. They seem to be able to use their devices just fine. >That leaves a large margin for error and user confusion, and no room at >all for providing a default state for nodes. The kernel provides the default state for nodes. When a user first encounters DEVFS, they will not immediately think to alter some prototype file, so as system designers, we have to ensure that the default state of the system is fairly secure. This has been the policy for MAKEDEV entries since before I joined the project. Prototypes won't deal properly with normal user's activities anyway. If I perform a "rm ttyd*" in my DEVFS directory, there is no way for the system to turn that into a wild-carded prototype, and even if it could, the system has no real idea of the user's intention. Did they use the wild-card to avoid typing or because they want to remove all future devices of this type? If you insist that some kind of prototyping scheme is still necessary, take care of it using a daemon forked by mount_devfs that shares a socket with DEVFS in the kernel and is notified of mount and arrival changes so it can modify the permissions. I think that it should only act as surrogate for performing rm/chmod/chown operations on devices that match a regexp, but that the persistent file store should still be handled as easy to manage underlying files. This means that should the daemon die, your DEVFS still retains the last set of permissions it was given and no reliance on the user daemon to perform any DEVFS operation is required. This means that should you do the types of operations that a normal user does (rm, chmod, undelete, etc), they work as expected daemon or no. If these operations are not enough for you, you can add prototypes to this special file. The result is a process that spends almost 100% of it's time swapped out and much avoided kernel bloat. >-- >\\ Sometimes you're ahead, \\ Mike Smith >\\ sometimes you're behind. \\ mike@smith.net.au >\\ The race is long, and in the \\ msmith@freebsd.org >\\ end it's only with yourself. \\ msmith@cdrom.com -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802161829.LAA19996>