bernstei@hpuxa.ircc.ohio-state.edu (Dan Bernstein) (08/29/89)
Suppose that a pty is just a two-way Stream module without a file
system entry. We can easily preserve all tty functions, and many
security problems disappear. This fits well with and simplifies
Steve Bellovin's ``session'' concept.
Objection 1: How do you multiplex another outgoing data stream
with the output of the shell (and its children)? For example, how
do talk and write work? Simply put the multiplexing into telnetd,
where it belongs, using any appropriate IPC mechanisms. Under the
session manager, an easy solution is to have a ~/.sessXX file for
each session; anything written to .sess* would be multiplexed into
the session, and talk/write would act accordingly. This also solves
the problem of ptys that are not connected to interactive shells;
the ptyd in this case would not set up a .sess file, and programs
like wall would not interfere with the output.
Objection 2: How do you output directly to /dev/ttyxx if it's not
there in the filesystem? How do you get around redirection? Well,
hopefully the fd 3 connection to the terminal will remain sacred,
i.e., that new convention will be uniformly respected. Then there's
no need to refer to the tty or pty by name.
This ``terminal module'' can be used for physical ttys as well.
/dev/tty02 could be replaced by /dev/modem02, which simply sends
characters through without any pretense at tty interpretation;
then getty would grab a pty, i.e., a terminal module, just as
telnetd and rlogind do. The only difference would be the origin
of the connection.
Discussion?
---Dan Bernstein, brnstnd@stealth.acf.nyu.edu,
bernstei@hpuxa.ircc.ohio-state.edu