Xref: utzoo comp.unix.wizards:25201 alt.security:2340 Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!dali.cs.montana.edu!milton!mrc From: mrc@milton.u.washington.edu (Mark Crispin) Newsgroups: comp.unix.wizards,alt.security Subject: Re: BSD tty security, part 3: How to Fix It Message-ID: <1991Apr29.001327.27805@milton.u.washington.edu> Date: 29 Apr 91 00:13:27 GMT References: <12535@dog.ee.lbl.gov> <15896:Apr2714:35:3991@kramden.acf.nyu.edu> Organization: University of Washington, Seattle Lines: 43 In article kre@cs.mu.oz.au (Robert Elz) writes: >The real problem is that the whole model used by "write" is simply >wrong - sure its simple, and in a sense, elegant, but its simply >not the way that things should be done. > >The whole concept of some other random process, owned by some other >random user, being able to open a direct channel onto my terminal, >however the output is massaged, or identified, or restricted, is >simply silly. Hopefully this is well understood by now. Fortunately I never worry about it, since I rarely use multi-user Unix systems. The only thing I use our departmental Unix engine for is as a mail drop, and even then I read the mail remotely. >The "modern" way where /dev/ttyX is mode 620 and "write" is setgid "tty" >is safer, but now means that I can't create my own "write" like program >with my own preferred user interface, I can only use one of the standard >ones. > >What's worse, the appearance of the message that I get to see depends >on the interface that the sending user has decided to select. On TOPS-20, you could create your own "write" like program, but it had to go through either a system call or daemon that enforced various restrictions on the contents and length of the text. The call/daemon also wrapped the message with header/trailer text so there was only one way for text to display. >This is all absurd - clearly the intelligent way to run things is for >messages that come from another user to be displayed the way I want them >using a process I control - then I can have the message displayed using >whatever interface I desire This is exactly how ITS worked. You opened a core-link (pipe) to the destination HACTRN (shell) and sent it a string. The receiving HACTRN could decide what, if anything, it wanted to do with the string including refuse to open its end of the core-link if the user didn't want to receive sends (writes). It is so wonderful to find that in the 1990's we are rediscovering technology of the late 60's/early 70's. 1/2 ;-)