BSD tty security, part 3: How to Fix It

[Chris Rende]

>From article <15896:Apr2714:35:3991 at kramden.acf.nyu.edu>, by brnstnd at kramden.acf.nyu.edu (Dan Bernstein):

Anyone who has ever used Multics should find this thread quite amusing since
Multics handles user to user messages quite nicely and consistently.

> 1. Do people think it's a problem that lines from ``write'' are not
> identified?

Yes.

When a user sends a 'write' type message to another user, it appears like this:

From: Chris Rende (car.user) tty11 Mon Apr 29 13:36:24 EDT 1991:
Line of text

Subsequent lines from the same user appear like this:
:= Line of text

This tells you that the line of text came form the last message sender.

If another person sends you a message, you get another full header like above.

Let's say that you have more than one user sending you messages...
If a new message comes in, and it is from the last identified sender, then
you get the ':=' prefix.
If a new message comes in, and it is not from the last identified sender,
then you get this:
(Chris Rende) := Line of text

> If nothing else, I like the ability to carry on two or three
> write conversations at once without getting totally confused. If others
> don't like this, though, then I'll stop pushing for it.

I like it too! See the above example.

> 2. Do people think it's a problem that someone can start a ``write'',
> then just type EOF or EOT to simulate ending it, then continue typing
> without identification? While most experienced users will guess exactly
> what's going on, novice users are really up the creek. Does anyone agree
> with Jef that it's ``disgusting'' to see
> 
> 	Message from operator at kramden on ttyp7 at 10:24 ...
> 	operator: this is where the text goes
> 	operator: and so on
> 	End of message from operator at kramden on ttyp7 at 10:25

I like this because you can tell where each line comes from.

That's why Multics preceeds a message line with ":=" so you know where it
came from.

> 3. Do people think it's a problem that ``write'' can flood a terminal
> with output before the recipient has a chance to react?

Kinda - but it's too bothersome to do anything about it. Having the ability
to switch messages off is sufficient. (mesg n).

> My version
> limits output to 500 characters per line and one line a second.

What if I'm using 300 baud? The meter of "what is too much data" changes
based on a number of factors...

> Does
> anyone think that this affects legitimate uses of ``write''? If not, is
> there any harm in adding the protection against accidents and abuse?

I don't think that it's worth the bother. And yes, in my college days we
used to 'zap' people by flooding them with messages - it's all part of the
fun. :-)

Actually, I think that there is a more fundamental problem: I think that
it is a crime for anyone to be able to open the device file which I am
connected to.

I would rather see messages implemented via a signal to my shell. The
shell can gather messages, format and identify them as above, and output
them when I am ready to see them. That's another nice thing about Multics:
polite mode.

Don't you just love it when lp (or whoever) sends you a message which
wipes out what you are typing? I hate that.

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).

Multics also has a "stty replay" mode. If Multics does interrupt you while
you are typing then it will re-display the line which you were typing
so that you can continue from where you left off.

car.
-- 
Christopher A. Rende           Central Cartage (Nixdorf/Pyramid/SysVR2/BSD4.3)
uunet!edsews!rphroy!trux!car   Multics,DTSS,Unix,Shortwave,Scanners,UnixPC/3B1
car at trux.mi.org                Minix 1.2,PC/XT,Mac+,TRS-80 Model I,1802 ELF
trux!ramecs!car     "I don't ever remember forgetting anything." - Chris Rende