BSD tty security, part 3: How to Fix It

[Robert Elz]

jik at athena.mit.edu (Jonathan I. Kamens) writes:

>  Your code may not be available yet, but Project Athena's Zephyr is.

Yes, I know about Zephyr, and probably should have mentioned it
explicitly - several other people brought it to my attention, for
which I thank you all.

However, these things aren't quite the same - Zephyr is solving a
much bigger problem than most of us need solved, and at least doesn't
seem to solve all of the problem that we actually do want to solve, it
would seem that the stuff being done here could adequately be turned
into Zephyr clients though.  Or, perhaps, might be able to be.

In particular, we're only interested in interactive messaging (that
stuff that currently opens /dev/ttyXX and blats noise onto it).  User
location, ... are outside our scope, and unnecessary in our environment
(its just not that big - furthermore, its not often necessary, you can
usually address a user on your local node, he will have arranged for
the message to go wherever he wants to reveive messages).

But we are very interested in user presentation - the way that the
user actually gets to control the way that messages are shown and
which particular messages get shown at all (eg: I like a window to
appear showing me "biff" (comsat) type output from new messages that
arrive, then vanish a couple of minutes later - but I don't want
that for "noise" messages I get - where my definition of what is
noise changes from minute to minute).   That type of control is
the heart of the stuff here, and at least from the paper (which
I saw in the usenix proceedings originally, and just fetched and
read again - using the net is an easier way to find it than hunting
through shelves looking for proceedings...) it doesn't appear that
this is really what zephyr is doing.

Finally - the place I log in (my workstation) is not where I want
messages processed, ie: running a "zwgc" process here would be a
basic waste of (extremely) scarce workstation resources.  Our stuff
requires no permanently running processes at all - apart from inetd
which is going to be there anyway.  Inetd starts a daemon when a message
arrives, that daemon becomes me, and does my will to the message.
Should someone actually send a message to my workstation (as I said,
no user location stuff, people can do that if they desire), that
daemon will run for just a short while, redirect the message off
to the host where I want to do the processing for it, and tell the
sender they sent to the wrong place and are being forwarded.

Maybe I should grab zephyr and have a more detailed look at it??

kre