ttyd

[mrose.uci at rand-relay]

From:  Marshall Rose <mrose.uci at rand-relay>

[This message is a bit long, so be prepared to interrupt...]

    We've got a terminal access mechanism at UC Irvine that you might
    be interested in.  The ttyd system arbitrates the action that
    occurs when a process wants to write to a control terminal other
    than its own.  The idea is that users have their terminals
    protected 0600, and then use a program called tact to set the
    action that occurs when a process wants to write to their terminal.
    The tact program lets the user choose from a large number of
    actions to be taken, including regular writing (with those nasty
    ctrl-chars normalized), refusal, re-direction to a file or pipe or
    port, etc.  Writers also get more functionality: programs such as
    write can write to users on other hosts, or do broadcasting without
    much fuss, etc.

    The ttyd system works by using a network daemon running as the
    super-user.  The daemon keeps track of what you want done when a
    process writes to you, and answers requests from processes want to
    do the writing.  Naturally, ttyd uses your [ug]ids and environment
    before actually performing the terminal action that you've set.

    If you want a copy of ttyd, let me know.  It's public domain (ah
    the joys of working at a UC), so we can freely distribute the code
    for non-commercial purposes.

    Okay, here's the bad news:

    - ttyd runs on 4.1a (well, that's what we run here.)  If someone
    wants to modify it for 4.1c/4.2, GREAT!  But, you must agree to
    send your changes back here, as public domain code, so we can
    include them with the rest of the ttyd code.

    - There are two bsd programs which get modified: write and comsat.
    I really can't send out the *complete* modified sources, so I'll
    send you a diff instead.  But, if you send us a copy of your UNIX
    license, I'll be happy to send the actual code itself.

    - Also, I'd prefer it if you didn't distribute ttyd, but instead
    direct requests to me.  This is for the usual reasons of updates,
    etc.

    - Finally, the UC Regents have a disclaimer for all of our
    software, containing the usual business about no responsibility
    etc., etc.  I'm interested in getting back modifications, reports
    and so forth, but ttyd isn't "supported".

    Okay, given all that, if you want a copy of ttyd, send me a mail
    message stating:

    - network mail address to send the code to (CSnet, Internet, UUCP
      addresses preferred, in that order).  I really wish we had an
      internet connection, so this code could be ftp'able.  But we
      don't, yet, so netmail it is.  Or, you could send a tape, my
      postal address follows.

    - if you don't like diff listings, you'd better send me a copy of
      your UNIX license.  My postal address is:
	Marshall Rose
	Department of Information and Computer Science
	University of California, Irvine
	Irvine, CA  92717

    - If you are running UDel's MMDF code, say so, I've got a rcvmail
      hook for you.  Our version of Gosling emacs (the pre-Unipress
      release) has been modified to use the ttyd facilities.  I am told
      by a site with the Unipress release that the changes can be
      merged in quite readily.  So, sites running gosmacs should watch
      the Unix.Emacs at CMU-CS-A list for a forthcoming announcment in a
      few weeks.


    That's about it.  At the end of this message I've put the manual
    entry for tact, so you can get a better idea if you want ttyd.  I'm
    sorry about the length of this message, but that's life.

/mtr

BTW - I'm interested in hearing about any other interesting network
software.  If you know of something interesting, why not drop me a note
about it.  Thanks.

#! /bin/csh -f
echo 'Extracting tact.1'
cat <<'//go.sysin dd * xyzzy' > 'tact.1'
.TH TACT 1 7/4/83
.SH NAME
tact \- terminal action
.SH SYNOPSIS
\fBtact\fR
\%[\-all]
\%[\-quiet]
option
\%[args]
.SH DESCRIPTION
The \fItact\fR program is the user\-interface to the \fIttyd\fR server.
By using \fItact\fR, the owner of a control terminal can specify what
actions should occur
when a process not belonging to the control terminal wants to write to
it.
.SH OPTIONS
The \fItact\fR program supports a large number of requests that the
user can give to \fIttyd\fR.
.TP 20
.B "file name"
Whenever a process wants to write to your terminal,
its output will be appended to \fIname\fR instead.
.TP
.B "mail \%[address]"
Whenever a process wants to write to your terminal,
its output will be mailed to \fIaddress\fR instead.
If \fIaddress\fR isn't specified,
then the output will be mailed to you.
.TP
.B "pipe command"
Whenever a process wants to write to your terminal,
its output will be supplied as the standard input to \fIcommand\fR instead.
If \fIcommand\fR produces any output, then that is written to your
terminal.
.TP
.B "port rhost portno"
Whenever a process wants to write to your terminal,
a socket will be created and connected to port \fIportno\fR on remote
system \fIrhost\fR.
The output of the process will then be sent to this socket.
.TP
.B "refuse"
Whenever a process wants to write to your terminal,
the process will be denied permission to do this.
.TP
.B "status \%[\-all] \%[lines...]"
Reports on the action that will occur when a process wants to write to
a particular control terminal.
If no arguments follow,
then the action associated with your terminal is described;
if \fI\-all\fR is used,
then all terminals are described;
otherwise the terminals you name are described.
.TP
.B "write"
Whenever a process wants to write to your terminal,
the process will actually get to write to your terminal.
.TP
.B "push"
The current action is pushed onto a stack, and remains unchanged.
This is useful for programs like \fItsink\fR,
which want to save and restore the user's terminal action environment
at the beginning and end of execution.
.TP
.B "pop"
The current action is set to the terminal action environment popped
from the stack.
.PP
Use of the \fI\-quiet\fR switch will prevent \fItact\fR from printing
any messages when errors occur.
This is most useful when an invocation to \fItact\fR is placed in the
user's \fI\&.cshrc\fR file.
In cases like this when the user accesses the login over the network,
\fItact\fR clearly does not have a control terminal to access,
and would normally abort.
.SH "ENVIRONMENT"
When \fIttyd\fR performs an action for the owner of a control terminal,
it does so as that owner.
In particular, \fIttyd\fR will run with the owner's user and group id's
(according to \fI/etc/passwd\fR and \fI/etc/group\fR).
In addition, \fIttyd\fR will change its working directory to the
owner's home directory (or if it can't, then the root directory),
and set the following environment variables \fB$HOME\fR,
\fB$USER\fR, and \fB$SHELL\fR.
The \fB$PATH\fR and \fB$TERM\fR envariables are usually not set.
This means that the arguments to the \fIfile\fR and \fIpipe\fR
options are interpreted relative to the owner's home directory.
.SH "SEE ALSO"
tsink(1), biff(1), mesg(1), ttyd(8)
.SH DIAGNOSTICS
All amazingly cryptic.
.SH BUGS
Interaction with \fImesg\fR can be confusing for users.
It is best to add \*(lqmesg n\*(rq to your \fI\&.login\fR file,
followed by an invocation of \fItact\fR.
.PP
Also, use of the \fImail\fR option can be dangerous.
If, when you receive mail, you normally get notified
by the mailsystem (e.g., with \fIbiff\fR or \fIrcvtty\fR),
then using \fItact mail\fR is likely to create an infinite pipe.
Use the \fImail\fR option with some discretion.
Some sites in fact, may remove the \fImail\fR option from \fItact\fR.
You can still get into problems though by using the \fIpipe\fR option.
'//go.sysin dd * xyzzy'