henry (12/30/82)
"An awful lot of programs are written by people who dont have root access that obtain information by reading kmem. Chances are that they might not have been written without free read access to kmem." ***FLAME ON*** Such programs should never have been written at all, then. This is the worst kind of machine-dependent, system-dependent, system-version-dependent, phase-of-the-moon-dependent code. People who leave kmem unprotected for this purpose are encouraging the sort of thing that happened to RT-11: practically every program depends on pawing through the system's internal data structures, to the point where it is very difficult to change, optimize, or rewrite parts of the system without breaking things. The de facto effect of making kmem generally readable is to increase the complexity of the kernel<->process interface by about three orders of magnitude, in a hopelessly machine-dependent and implementation-dependent way. (And the less said about programs that *write* on kmem, the better.) ***FLAME OFF*** More practically, there are at least five reasons for disallowing general access to kmem. Not every site has all of these considerations, but most have at least some: 1. Security. Even systems that do nothing but software development can have confidential material around for "real" test databases or for reproducing obscure bugs found on "production" systems. And if you have any dialups at all, you cannot *guarantee* security by restricting access to the system -- the incidence of easily- guessable passwords is just too high. Uucp security bugs can make dialout modems equally vulnerable. 2. Privacy. Even when your system has no security worries at all, it is still pleasant to be able to send private mail to your girlfriend (or your boss). Electronic mail is a very useful means of communication, and not all of the messages are intended for public consumption. The same applies, to a lesser degree, to more general facilities like the file system. 3. Growth. It is not at all improbable that, someday, you will want to move to a new type of cpu. The odds that kmem-reading programs will continue to work over such a transition are not all that good. It is *very* probable that someday you will want to move to a new version of the operating system, and that is almost guaranteed to break *all* kmem-reading programs. 4. Simplicity. Any program that reads kmem is dealing with a far more complex interface to the system than the clean, simple, safe one provided by files and system calls. The possibilities for subtle bugs and misunderstandings are obvious, even assuming that the hardware and the kernel are completely frozen. Sure, "kmem was _designed_ to be readable" -- mostly to make it possible to do ad-hoc monitoring and debugging without having to build "clean" interfaces for one-shot requirements. Those are the only places I can find where it is used in V7 as Bell distributes it. (I cannot speak for x.yBSD, although I fear the worst.) 5. Portability. Someday, you will probably want to run some of your software on somebody else's machine or somebody else's kernel. Within one mile of where I sit, a text editor that I had a hand in building is running on machines ranging from a breadbox-sized Intel machine to a monstrous 3033 that would be in the running for the World's Biggest Unix Machine. There is little hope of doing this sort of thing unless you stick to the "official" interface to the system. In conclusion, the right way to handle such situations is to build clean interfaces for the things you really need. It's true that locally-built system calls will not be very portable -- but neither are locally-written definitions of the kmem data structures. By the way, Michael A. Bloom (from whom the above quotes are taken) is wrong -- there is a way to test for pending input in the absence of the "get number of chars to be read" ioctl, on V7 at least. It is a little inefficient, and the ioctl is certainly preferable, but it is ***NOT*** necessary to read kmem for this particular task. "Creativity is no substitute for knowing what you're doing." Henry Spencer U of Toronto