mrose.uci@rand-relay@sri-unix.UUCP (07/26/83)
From: Marshall Rose <mrose.uci@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@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'