Date: Mon, 16 Feb 1998 15:38:57 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: Mike Smith <mike@smith.net.au> Cc: 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: <199802162241.PAA00744@pluto.plutotech.com> In-Reply-To: Your message of "Mon, 16 Feb 1998 12:57:42 PST." <199802162057.MAA07674@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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. In todays system, if a "new device arrives", I hook it up to my machine, and expect to perform some amount of configuration to make that new device work. This could include adding kernel device support for it, adding the device to a cron job or other script, telling the user community about it, etc. In the world without DEVFS, this would also include the necessity of running MAKEDEV to create the node and, if the permissions weren't adequate, chmod/chown type operations. The only difference in this scenario with DEVFS is that the default node comes into existence automatically, but the user will still expect to have to modify permissions before the device is guaranteed to be completely usable. The only issue I see, is one of security with DEVFS. Some admins may not want new device arrivals to show up auto-magically. >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 a problem unless there is a security issue, and I have already proposed a method for dealing with security issues with an option to only allow devices to show up that have a backing object. The user community already expects to have to modify the permissions of new device nodes if the defaults don't suit their needs... why is this any different. >> >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) Devices that don't have a backing store don't show up, so how can new device arrival compromise the security of the system? >> 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"? I listed ptys in my original comment. >> >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* And st*, right? This will happily match stdout, stderr, and stdin. And what if you don't want your rule to affect the control devices? I suppose that you will introduce some sort of ordering so that later entries override matches from previous ones? Now you have to provide an override that specifically restores the default permissions. What happens if someone adds a new device name that just happens to match one of your "prototypes" by mistake? You might never even notice this, but the security ramifications could be large. What happens if you attempt to chmod/chown a file that has a protoype? I think the user would be really confused to find those operations ineffective. The more I look at this prototype stuff, the more I dislike it. >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). These don't include character class globbing which I think you'd need here (see my stdin, etc. example). >> 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? You're talking about feeding an arbitrary file into a kernel provided parser. I think I'll use /bin/cat as my prototype file and see what happens to my system. What happens if the filesystem, and your info file, gets trashed? >> 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. The Hummer can go many places the Range Rover can't. Try taking that RR up a 60 degree slope. >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. And saying, "If you mount your DEVFS on a directory that just happens to have a 'devinfo' file, you get magical DEVFS properties", is intuitive? >> 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. Which happens when?? In either scenario, you may end up leaving trash in the mount point. Of course, in the current system you have to have a file per node anyway... >> 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. Why would it be tedious? >> >... 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? The first person I heard voice a desire to do this was PHK. I like Poul a lot, but I don't think we should put every feature Poul wants into FreeBSD. You have since taken on his argument too, but who else? The other people I've heard in this discussion have voiced concerns about being able to do what they can do today without DEVFS, with DEVFS. >> 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. This is not what I have proposed. New nodes are configurable in that you can configure the system to either show them or not. This gives you the option to get exactly the same functionality as the current system. >> 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? I already proposed one. The "backing store only" option prevents new device arrival from perturbing the "state of the world" the admin setup. The only difference is that you must explicitly specify the devices you want, not the devices you don't want. >> 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 Which I don't. > , and you > accept that local policy may want to be arbitrarily strict, then > new nodes have to arrive with no permissions whatsoever. Nope. The mount mode could specify that no new node can be made visible until after the daemon has been notified and acked the notification. I could easily envision a system where you only go into "daemon mode" when a specific mount option is specified. While the system is in SU mode, you rely on whatever backing objects exist to modify permissions but still display all devices. When you transition to MU, you "mount -u" DEVFS to start up the daemon which applies any prototypes you have specified and starts up this protocol. > 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. Use some imagination. The protocol can be specified such that the worst case scenario is that new device nodes do not show up for a DEVFS that is configured to rely on the daemon. The kernel should never have to block FS requests because the daemon died. > - A userspace daemon would be inefficient for embedded systems, which > is one of the prime targets for DEVFS. Embedded systems should directly modify the kernel source to get the default permissions the way they want. I don't buy the inefficiency argument either. Device arrival events should be rare. How often do you expect them to happen? Once a second is still a relative eternity between arrivals. > - The coupling between a set of device nodes and the backing store for > their attributes is looser than might be desired. Actually it is tightly coupled since you don't need the daemon or parser to get back all of the setting you've set in the past. >> 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. It only assumes a persistent backing store if you want permissions to be retained across reboots. Of course, your scheme also has this requirement since the permissions have to be recorded somewhere. >Basically, you're agreeing with everything that's been proposed, except >that you want to put the rule parser in a daemon. I still severely question the need for this functionality, but if it's determined that it must exist, I don't want to see the kernel bloated to provide it. >Which just puts the >bloat in swap space, along with yet another copy of large parts of the C >library. Disk space is still much cheaper than RAM. >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. The kernel can't be swapped out. -- 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?199802162241.PAA00744>