Slaying Gould dragon with a wooden hoss

[Doug Gwyn]

In article <1307 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
>As a matter of fact, unless the /dev device associated with the
>terminal is world-unwriteable (mesg n), simply "cat hacker.file > /dev/console"
>is a dangerous possibility for a logged-in-as-root block-mode terminal.  SO
>WHAT if "write" is prissy about what it sends? :-)  ("write" is normally not
>setuid root anyway, so fixing it to filter out escape sequences wouldn't
>help anything that a "mesg n" wouldn't also help.)

Oh, I was taking for granted that one had already taken care of world-
writable /dev/tty* inodes anyway.  "cat nuisance >/dev/ttyXX" has long
been a possible source of discomfort.  BRL UNIXes require use of special
privileged "write", "wall", etc. that honor the convention that the "x"
bit (not the usual "w" bit) indicates writability.  4.3BSD seems to have
the idea that set-GID "tty" group processes should be used to write
other people's ttys.  Undoubtedly other such approaches are possible.

Certainly you need to take care of this, as well as having "write" etc.
filter escape sequences, to avoid the block-mode terminal problem.

By the way, a related issue is the need to distinguish between the
following "mesg" states for a tty line:
	- anyone may send me a message
		(typical normal shell)
	- only a system administrator may send me a message
		(to get relief from bad citizens, for example)
	- NObody (other than myself) is allowed to send me anything
		(special protocol port, downloaded layer,
		or hardcopy device busy printing a document)
as well as the following distinction:
	- this is the tty line to send me messages on
		(communication layer)
	- this is NOT where I want messages sent
		(other layers)
Not all combinations of who(utmp)/mesg/write/wall support all these
distinctions; back when almost everyone had limited expectations for
ttys, it wasn't important, but now that networking and windowing
systems are widespread, this needs to be dealt with.