z (03/24/83)
I saw a note about this a while ago, but I don't recall a solution being mentioned. For some unknown reason, the news output from decvax to us dropped off by about 80% last week. Then yesterday at noon, decvax called us up and poured out a week's accumulation of news over a three hour period. After the dust had settled, I looked in /usr/spool/uucp and found that there were still 143 D.* files full of news, but only about 50 X.* files. Furthermore, though the X.* files should have referenced files with "cca" in their names, only two of them did; the rest referenced strange machines which I assume are all neighbors of decvax. The two X.* files which did reference cca files actually referenced nonexistent files. I had no choice but to flush all of the X.* files and build by hand (actually, by keyboard macro) a new set of X.* that properly referenced all of the D.* files. Once I did this, I cranked up a uux, and all 143 D.* files got properly fed into rnews. Does anyone know what happened to all of the X.* files that should have come with the D.* files? Furthermore, why did I get all of those X.* files which were bound for other machines? Does this mean that other people got my X.* files? Is this a problem with decvax's uucp, or with mine? And finally, does anyone have a fix? Steve Zimmerman decvax!cca!z z@cca
henry (03/27/83)
Steve Zimmerman's problems come from a fundamental wart in uucp that has been known for a long time: the outbound X-files-to-be are stored under names that get re-used when the sending system's sequence number wraps around. With the volume of traffic decvax gets, the sequence number takes only a few days to wrap -- even though they use hex rather than base-10 so as to get a bigger range. The C-files and D-files are stored under filenames containing the destination system's name, so at least wraparound on them stomps only traffic bound for the same place. The X-files-to-be lack even this minimal protection. So, Steve, the X-files that should have gone with your D-files got sent to other machines because the names got re-used. And this also explains why you got X-files bound for other machines. The problem, insofar as it can be localized to sites rather than to software, is at decvax and not at your site. And fixing it is hard. About the only thing to do is to use a much bigger alphabet for the sequence numbers so that the range is much larger; I think Alan Watt published some routines for this a while ago. The hard part is convincing the folks at other sites (in this case, decvax) to install them. Sites that are on Mark's new network backbone should be STRONGLY encouraged to do something like this. (Are you listening, Armando?) Henry Spencer U of Toronto
johnl (03/27/83)
#R:cca:-449200:ima:13900001:000:2253
ima!johnl Mar 26 11:03:00 1983
Steve Zimmerman (cca!z) complains that decvax uucp's files to his site
that should have gone elsewhere.
This is a known bug (to me at least) that exhibits much of the
fundamental cruftiness of uucp. The scenario is like this:
1. decvax decides to make a few phone calls, so it runs uucico which
scans through its spool directory and finds a C.--- file aimed
at, say, cca.
2. It reads the directory to get a list of C.--- files for the
chosen site.
3. It starts reading the C.--- files and transferring the stuff
contained therein. So far, so good.
4. It snows in New Hampshire, the phone line gets noisy, and the
modem hangs up halfway through a transfer.
5. uucico decides to call somebody else, so it makes a new list of
C.--- files for somebody else, and calls them.
6. In a frenzy of overoptimization, uucico notices that it already
has a C.--- file open and reads command lines from it.
Unfortunately, this means that it is sending files destined for
the old site to the new site. Oops.
The fix for this is straightforward but messy. It is on the uucp bug
list at Tektronix. My uucp sources are currently off on tape but if
there's enough demand, I can dig them up and post the changes again.
Note that sites with a lot of uucp traffic, PARTICULARLY DECVAX, should
install this repair.
There's also a benign bug with similar symptoms, in that you end up with
X.--- files with no D.--- files to match, but the X.--- file is one that
belongs to you. This happens when the modem hangs up after the X.---
file is successfully received by the receiver but the sender doesn't know
yet. The receiver cherrfully processes and deletes the X.--- and D.---
files, but the sender later re-sends the X.--- file anyway. Look in the
uucp LOGFILE to see if orphaned files got transferred twice; if they did,
don't worry about it. On the other hand, if you get X.--- files for
other sites, you got trouble and your neighbor site should install the
repair discussed above right away.
John Levine, IECC, PO Box 349, Cambridge MA 02238; (617) 491-5451
decvax!yale-co!jrl, ucbvax!cbosgd!ima!johnl
{uscvax|ucla-vax|vortex}!ism780!johnl,
{research|alice|amd70|cca}!ima!johnl
Levine@YALE (I hope, again.)stevenm (03/29/83)
This is bug #4 on the UUCP BUG LIST. John was the person responsible for
the fix. (Thank you John!).
S. McGeady
Here is the text of bug #4:
4) X.* FILES DEPOSITED ON WRONG SYSTEM
From: teklabs!decvax!cca!ima!johnl
Date: Wed Nov 3 16:08:00 1982
Subject: Important uucp security bug
Newsgroups: net.bugs.uucp,net.unix-wizards
References: anlwrk.c,anlwrk(),cntrl.c,cntrl()
You may have noticed X. files lying around in your uucp spool directory
which, when you look at them, appear to have been intended for other
sites. This turns out to be the most obvious case of a general bug in
which any site that calls out can send files to sites other than the one
they should have gone to. Quite a security hole, eh? This problem is
most notable at sites which are polled by decvax, since decvax calls out
and gets hung up on a lot. (Hint: decvax - try installing this soon.)
The problem is as follows. When uucico calls a site and copies files
across, it opens a C. file for that site and reads command lines from it
one at a time. If the connection should die before all of the command
lines in that file have been processed, and it then goes and calls a
second site, it continues reading command lines from that command file!
Oops. Fortunately the fix is quite simple. These changes are for System
III uucp, but I think the code is the same in V7 and BSD.
In cntrl() in cntrl.c near line 118:
pnum = getpid();
Wfile[0] = '\0'; /* ADD THIS NEW LINE JUST BEFORE top: */
top:
DEBUG(4, "*** TOP *** - role=%d, ", role);
In anlwrk() in anlwrk.c near line 30, add these lines and adjust the
curly braces to match:
if (file[0] == '\0') { /* { IS NEW */
/* begin new code */
if(fp != NULL)
fclose(fp);
fp = NULL;
/* end new code */
return(0);
} /* } IS NEW */
These changes just make sure that it closes any open command file when it
calls iswrk() to look for new work for a new system. Yes, I have tested
this and hung up on myself and all and it really works.
John Levine, IECC, PO Box 349, Cambridge MA 02238; (617) 491-5450
decvax!cca!ima!johnl, harpo!esquire!ima!johnl, ucbvax!cbosgd!ima!johnl,
yale-co!jrl (all uucp), Levine@YALE (Arpa).
--------jreuter (03/30/83)
I have gotten misdirected X.* files from both decvax and cbosg on this machine, though only occasionally and one at a time. Sound to me like another latent uucp bug. Anyone fixed this one yet? Jim Reuter (decvax!cincy!jreuter)
essick (04/01/83)
#R:cca:-449200:uiucdcs:18600003:004:1773
uiucdcs!essick Mar 31 11:00:00 1983
Ah the advantages of never expiring net.bugs.xxx! The uux problem
which sends X.* files to the wrong machine has been found and repaired.
Here are the appropriate portions of the note which explained the problem
and presented the solution.
I haven't tried this one myself, but we haven't had the problem
locally.
-- Ray Essick, University of Illinois.
***** uiucdcs:net.bugs.uucp / ima!johnl / 4:08 pm Nov 3, 1982
...
The problem is as follows. When uucico calls a site and copies files
across, it opens a C. file for that site and reads command lines from it
one at a time. If the connection should die before all of the command
lines in that file have been processed, and it then goes and calls a
second site, it continues reading command lines from that command file!
Oops. Fortunately the fix is quite simple. These changes are for System
III uucp, but I think the code is the same in V7 and BSD.
In cntrl() in cntrl.c near line 118:
pnum = getpid();
Wfile[0] = '\0'; /* ADD THIS NEW LINE JUST BEFORE top: */
top:
DEBUG(4, "*** TOP *** - role=%d, ", role);
In anlwrk() in anlwrk.c near line 30, add these lines and adjust the
curly braces to match:
if (file[0] == '\0') { /* { IS NEW */
/* begin new code */
if(fp != NULL)
fclose(fp);
fp = NULL;
/* end new code */
return(0);
} /* } IS NEW */
These changes just make sure that it closes any open command file when it
calls iswrk() to look for new work for a new system. Yes, I have tested
this and hung up on myself and all and it really works.
John Levine, IECC, PO Box 349, Cambridge MA 02238; (617) 491-5450
decvax!cca!ima!johnl, harpo!esquire!ima!johnl, ucbvax!cbosgd!ima!johnl,
yale-co!jrl (all uucp), Levine@YALE (Arpa).
--------
----------