gill (07/14/82)
A bug in anlwrk.c causes uucp to core dump after a perfect
login and startup. This happens when there is an unwritable A.xxx file in the
spool directory. Trouble is, anlwrk() in anlwrk.c doesn't check the
stream it gets from fopen against NULL before trying to do an fprintf
of the command lines completed count onto the file.
afp = fopen(afile, "w");
fprintf (afp, "%d", acount);
fclose(afp);
should be changed to
if ((afp = fopen(afile, "w")) != NULL)
{
fprintf (afp, "%d", acount);
fclose(afp);
}
The A.xxx file was owned by root on our system (somehow) and mode
0644, due to WFMASK (in uucp.h) being 0133.
The core files landed in /usr/spool/uucp, but were of zero length.
This was an extreme pain in the ass, as the symptom only showed
up when uucico was run from an ordinary uid with the setuid bit
on. The "no core files for setuid programs" restriction in the 4.1
kernal should happen before the if (ip== NULL) ... mknode(0666),
not after. A better idea is to escape this test if the core file did not exist
before and the link count is still one. Anything but the misleading
documentation (only found in sig.c) stating that core dumps can in fact
happen to setuid programs.
On another front, I have repaired a bug with dialup() in conn.c.
The multiple calling of multiple phone numbers during a single attempt by
uucico to contact a system didn't work.
This was because the alarm call which interrupted the "waiting for
carrier" open of the dz data line left the DTR bit high. Our DN dialer
refused to dial again on this line, since it thought it was busy. The only
way to lower DTR was for uucico to exit, since there was no file
descriptor to do a close on (open never returned). Luckily, as
there was a tty structure associated with that dz line, the exiting
of uucico caused a call to dzclose, lowering DTR.
I kludged up a solution by creating a child process which probed the DZ
line with its own timeout, and either sent a signal to uucico or died,
depending on whether or not open returned in time. Upon
receit of the signal, uucico opened the line for itself and killed the
child. If the wait returned instead, uucico just went on to try again;
the exiting of the child (the only one trying to open the dz line) caused
DTR to go low.
If anyone has had this problem and dreamed up a better solution, please
let me know. BTL UNIX 3.0 and beyond have no-wait opens, which offer a
much cleaner way of dealing with ACUs and their associated serial lines.
If there aren't any better ways around this in 4.1, I'll be happy
to send my version of dialup() to anyone interested. I've thought
of changing the 4.1 kernal to call dzclose when the open call is
aborted, but have decided that this wouldn't always be the right
thing to do.
Gill Pratt
reachable by mail at
....!alice!researc!physics!gill
or
gill@mc