Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!cs.umn.edu!sctc.com!stachour
From: stachour@sctc.com (Paul Stachour)
Newsgroups: comp.unix.wizards
Subject: Re: BSD tty security, part 3: How to Fix It
Message-ID: <1991Apr30.142053.2313@sctc.com>
Date: 30 Apr 91 14:20:53 GMT
References: <15896: Apr2714:35:3991@kramden.acf.nyu.edu> <542@trux.UUCP>
Organization: SCTC
Lines: 56

car@trux.UUCP (Chris Rende) writes:

  ... many things about the issue of tty security and how it should be
      implemented.

>On Multics you can issue the command "stty polite". Now, messages are
>not sent to the terminal unless/until the user hits return. (Or until/while
>the keyboard input buffer is empty).

  ... More deleted


Chris stated very well why it was "wrong" to allow arbitrary processes
to write to a device.  
However, Chris left out what I feel is the most important thing about
tty writes:

     HOW THEY ARE CONTROLLED.

On Multics, in a stock login, NO-ONE can write to your terminal.
Writes to your terminal are controlled by code that you allow.
Writes to your terminal are not writes to your terminal, but messages
placed in a "special repository". A event is then signaled over
the channel associated with that repository.

If you have issued the Multics command "accept_messages" you indicate
your willingness to be interrupted, and recieve messages in exactly
the style Chris mentioned.

However, if you are an emacs or X-window or ... style of person, you
can write (and many have written) a command to take the messages
from the repository and display them in the style you feel is best.
[One friend has one-buffer for messages from each person.]

The principles are:
      The USER has control of his login.
      The SYSTEM defers to the user's wishes.
      The SYSTEM provides an adequate interface at the subroutine level
          for sophoticated users.
      The SYSTEM provides a minimal USER level facility for those who
          choose not to write their own.

Gee, with that kind of understandings, its no wonder that those of
us who have used Multics are kind of upset when we are forced to migrate
to systems where
      The SYSTEM has control of our login (and interruptbility).
      The USER is forced to defer to the system's style on interruptability.
      The SYSTEM does not provide good subroutine-level interfaces.
      The minimal SYSTEM facility is not present.
           [Thank goodness this one doesn't apply here.]

Yours, ...Paul
-- 
Paul Stachour          SCTC, 1210 W. County Rd E, Suite 100           
stachour@sctc.com          Arden Hills, MN  55112
                             [1]-(612) 482-7467