[net.unix-wizards] bug in 4.2 tip

sid@linus.UUCP (Sid Stuart) (06/30/84)

Index: 4.2 BSD tip acu.c

Description: I ran into this about a month ago right before I went
on vacation. I forget exactly what was wrong, but I think if you set
the cm variable in /etc/remote to a non-null string, it would cause
tip to dump core and die. The cm string is supposed
to be sent to the computer you are connecting to. Unfortunatly, the
write statement uses the wrong character buffer, it is obvious that
the code is incorrect, if you look at it. The statement is

	pwrite(FD, cp, size(CM);

The problem is that cp and &CM point to different buffers. So if
cp points to a null buffer and &CM points to a buffer with a string in
it... you dump your core. The fix is simple, just put &CM in place of
cp. This fix will have the side effect that the program may do
what it is supposed to at this point.

Repeat: Like I said before, I have forgotten.

Fix:

*** acu.c.orig	Sun May 20 20:13:26 1984
--- acu.c	Sun May 20 20:28:17 1984
***************
*** 34,41
  	int tried = 0;
  
  	if (!DU) {		/* regular connect message */
! 		if (CM != NOSTR)
! 			pwrite(FD, cp, size(CM));
  		return (NOSTR);
  	}
  	/*

--- 34,41 -----
  	int tried = 0;
  
  	if (!DU) {		/* regular connect message */
! 		if (CM != NOSTR) 
! 			pwrite(FD, &CM, size(CM));
  		return (NOSTR);
  	}
  	/*

speck@cit-vax.ARPA (07/10/84)

From:  Don Speck <speck@cit-vax.ARPA>

Index: 4.2 BSD tip acu.c

Coincidentally, I fixed the bug in 'cm' here just an hour before it was
mentioned on Unix-wizards.  But I think what you want is:
$ diff -b acu.old.c acu.c   # look in routine connect()
41c41
<			pwrite(FD, cp, size(CM));
---
>			pwrite(FD, CM, size(CM));

instead of &CM as was claimed.	(This is what works here).

    Tip also has a problem with lockfiles.  It runs setuid to uucp,
makes a lockfile in /usr/spool/uucp/, throws away its setuid/setgid,
and much later it tries to remove the lockfile and can't.  Is there
a pre-existing fix to this one (using fork() perhaps?)	If so, can
someone point me to it?
						-Don Speck-

sid@linus.UUCP (Sid Stuart) (07/16/84)

	Whoops, Don is right about the correct fix to the tip bug;
but then you folks have seen enough dumb mistakes come from my terminal
that you know to double check anything I say.




			I swear, my finger slipped, ;-)
			sid

charles@utastro.UUCP (Charles Sandel) (07/17/84)

I have hacked 'tip' to be able to remove its lockfile (among other
things) by creating  yet another program which has as its task
to specifically remove lock files.  'tip' passes the name
of the lock, and the process and user id's to the server, which
does checks, etc, and then removes the  lock if the info passes
all tests.  I can send the source to those interested, but
probably someone else has done something better.

I've also done a few other things to 'tip', such as add user-settable
variables to contain AT&T credit card numbers.  Also, I've made 'tip'
be able to time itself out after a certain amount of time without
banging the keyboard.  This prevents someone from tying up the modem
indefinitely.

-- 
                     *>> Charles Sandel <<*
      uucp:  {ut-sally, ut-ngp, noao, charm}!utastro!charles
            arpa:  chaz@ut-ngp  or  charles@ut-sally
                      at&t:  (512) 471-4461 x439