Date: Mon, 16 Feb 1998 15:33:20 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Mike Smith <mike@smith.net.au>, Bruce Evans <bde@zeta.org.au>, dyson@FreeBSD.ORG, wollman@khavrinen.lcs.mit.edu, committers@FreeBSD.ORG, eivind@yes.no Subject: Re: devfs persistence Message-ID: <Pine.BSF.3.95.980216153251.8949U-100000@current1.whistle.com> In-Reply-To: <199802162241.PAA00744@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[please guys, can we move this to current?] julian On Mon, 16 Feb 1998, Justin T. Gibbs wrote: > >> 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?Pine.BSF.3.95.980216153251.8949U-100000>