[comp.unix.ultrix] Ultrix 1.2 uucp - spurious hangup signals

grr@cbmvax.UUCP (George Robbins) (02/10/88)

In Ultrix 1.2, uucico fails to correctly handle some hangup signals on
outgoing calls.  The results is that other members of the process group
that include the parent process that initiated uucico will get blasted
with undeserved hangup signals with greater or lesser frequency.

The most offensive expample of this is when a user is in an extended
mail reply session.  He replies to a message, which ends up starting
a uucp transfer, then sometime later when editing another message,
the uucp activity finishes, but lets a hangup slip through.  This
blows away any another reply he may have been entering and dumps him
out of mail.

When uucp or some command invoking uucp activity is started from the
shell, the problem isn't evident, since the shell (csh at least)
executes each command as a new process group.  It's only when uucp
is exec'd from another program or perhaps as a shell escape from a
program that you get burned.

Different modems may cause the observed frequency of the problem to
change, apparently due to different time delays when terminating or
aborting calls.

One fix is to replace uucico with a program that does a setpgrp() call
to create a new process group, divorcing itself from the initiating
process group, and then exec's the real uucico.  A suitable program
and procedure is included below.

It might also be possible to do this with a csh script that would
simply contain "#!/bin/csh", "/usr/lib/uucp/uucico.real $* &" however
this would create additional processes, and if you've ever seen the
mess when uucp and/or mail exceed the per-uid process limit, you
would most likely consider this undesirable.

The FIX: (Ultrix 1.2 - 1.1 is probably equally sick - 2.x fixed, I hope?)

1) you must be root (or the setuid bits will go away!)
2) uucico must not be running (ps -aux | grep uu)
3) you should know what you are doing...
4) copy the old uucico to some safe place
5) test uucico from a non-privledged uid before going home 8-)

enter the following source program (uupgrp.c)

------------ cut here -----------
/* this program extracts itself from the current process group
   and then exec's uucico.real.  This prevents hangup signals
   generated by uucp activity from blowing away innocent user
   processes that may have casually initiated uucp activity. */

#include <stdio.h>

long getpid();
char *uucico = "/usr/lib/uucp/uucico.real";

main(argc,argv,envp)
	int argc;
	char *argv[], *envp[];
{
	setpgrp(0,getpid());
	if (execve(uucico,argv,envp) < 0) {
		fprintf(stderr,"Can't exec %s\n",uucico);
		exit(1);
	}
}
------------ cut here -----------

do the following:

su
cp /usr/lib/uucp/uucico /usr/lib/uucp/uucico.backup
cc uupgrp.c
<correct errors 8-) >
./a.out
<should get "can't exec" message>
cp /usr/lib/uucp/uucico /usr/lib/uucp/uucico.real
./a.out -r1 -x9 -sdummy
<should invoke uuico with debugging>
cp a.out /usr/lib/uucp/uucico
ls -l /usr/lib/uucp/uucico.real
<make sure uucico is still suid uucp>
^D
/usr/lib/uucp/uucico -r1 -sdummy
tail /usr/spool/uucp/LOGFILE
<make sure any user can invoke uucico>