Date: Mon, 16 Feb 1998 12:57:42 -0800 From: Mike Smith <mike@smith.net.au> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Mike Smith <mike@smith.net.au>, "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: <199802162057.MAA07674@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 16 Feb 1998 11:26:50 MST." <199802161829.LAA19996@pluto.plutotech.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. Not entirely; you *don't* have the capacity to specify what a new device node should look like when it's created. Because you're not there waiting for it when it appears, there needs to be a mechanism whereby you can specify in advance what it should look like. The specific problem with using nothing but nodes behind the DEVFS entries is that you can never provide for all the entries that might appear without, you guessed it, a *script* that creates all these backing nodes. Doesn't that sound familiar? > >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 See above for how I feel about this. 8) > would also argue that a "secure" system would not have any device arrivals > (other than newly allocated ptys perhaps) during normal operation, and the You must be kidding. How about (for example) pty clones? Why is device arrival "insecure"? > >> 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]+ Sure; nrst* est* rst* I'd be more worried about tty[pqr]* to be honest. Regardless, a simple, generalised glob matcher would find consumers in quite a few parts of the system (SCSI/ATA/ATAPI quirk matching just for starters). > >> 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. So how is the proposed interface any different? > >> 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. I think we are perhaps debating the difference between a Hummer and a Range Rover here; both will get you where you want to go, the former with an air of macho masochism and the latter in comfort. Having been thrust out onto the sharp edge, I can tell you that any effort you are willing to let others make for the sake of a clean, intuitive interface will be repaid many times over. > >> 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? Anytime you wanted to mount the devfs somewhere else and have it behave like it currently does. > If you are doing this, what are the rules for reconciling permissions with > those that already exist in the target mount point? Either or. If the target mountpoint has rules, they're there for a reason. If it doesn't, the current system set provides reasonable defaults. > 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. It still doesn't deal with prototyping. Sure, you can plaster the nodes into a tarball, but extracting them would be tedious, especially if you had already mounted the devfs. > >> 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. Sure. We're not talking about these people, they're taken care of already. But you are suggesting via some sort of reverse elitism that we should abandon some of the basic features that people have asked for? > >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. Sure, and I was never proposing that the default state would, or should, be insecure. My point was simply that you are suggesting that there should be *no* configurable policy for new nodes. This is inferior to the current methodology, and unacceptable to more than a few people. I think your 99.99% figure is probably a lot further out than you think. > 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? The wildcard is never available to anyone other than the shell, so the point is moot. However, why are you opposed to providing a mechanism whereby they *can* provide a prototype to effect this removal? Do you have an alternative proposal that is capable of achieving this? > 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. We've been down this path before. A daemon has a number of fundamental flaws: - If you expect the daemon to take care of all permissions, and you accept that local policy may want to be arbitrarily strict, then new nodes have to arrive with no permissions whatsoever. However this means that the daemon has to be running before the system can come up (impossible), and that any failure in the daemon will effectively kill the system. - A userspace daemon would be inefficient for embedded systems, which is one of the prime targets for DEVFS. - The coupling between a set of device nodes and the backing store for their attributes is looser than might be desired. > 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 presumes that your DEVFS is mounted on persistent storage. > 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. Basically, you're agreeing with everything that's been proposed, except that you want to put the rule parser in a daemon. Which just puts the bloat in swap space, along with yet another copy of large parts of the C library. I don't buy the trivial size reduction as a benefit outweighing the drawbacks, and in the few cases where bloat is actually an issue, the size of the daemon's executable would be more of a penalty than the extra code growth in the kernel. -- \\ 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 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?199802162057.MAA07674>