Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site sequel.UUCP
Path: utzoo!decvax!wivax!linus!allegra!eagle!mhuxt!mhuxi!mhuxa!houxm!hogpc!houti!ariel!vax135!cornell!uw-beaver!tektronix!ogcvax!sequel!phil
From: p...@sequel.UUCP
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: YAMB (Yet Another Mail Bug)
Message-ID: <154@sequel.UUCP>
Date: Thu, 2-Jun-83 16:11:26 EDT
Article-I.D.: sequel.154
Posted: Thu Jun 2 16:11:26 1983
Date-Received: Thu, 9-Jun-83 00:44:38 EDT
Organization: Sequel Computer Systems, Portland
Lines: 93
There is another bug in 4.1 /bin/mail. I just had my third
complaint of mail getting mixed together so decided to fix it
once and for all. I looked through my bug files and found only
the comsat problem (fwrite to mail but no flush or close before
writing to comsat). I had already fixed the comsat bug.
I suspected the locking protocol was fubar (was running setuid
root, etc). This proved not to be the case. I tested it by
running the following script:
(mail -s "Try number 1" phil < /etc/passwd ) &
(mail -s "Try number 2" phil < /etc/passwd ) &
(mail -s "Try number 3" phil < /etc/passwd ) &
(mail -s "Try number 4" phil < /etc/passwd ) &
(mail -s "Try number 5" phil < /etc/passwd ) &
I found that usually only 1 to 3 copies arrived usually in a
jumbled order. Humm. Must be failing to lock the mailbox right?
WRONG! I crawled through the routine lock(), and lock1(). They
appear to be 100% ok. In looking at where mail does the local
delivery I noticed the following sequence of code:
mask = umask(MAILMODE);
---> malf = fopen(file, "a");
umask(mask);
if (malf == NULL) {
fprintf(stdout, "mail: cannot append to %s\n", file);
return(0);
}
---> lock(file);
chown(file, pw->pw_uid, pw->pw_gid);
{
f = open("/dev/mail", 1);
sprintf(buf, "%s@%d\n", name, ftell(malf));
}
copylet(n, malf, ORDINARY);
fclose(malf); /* here so comsat works! */
if (f >= 0) {
write(f, buf, strlen(buf)+1);
close(f);
}
/* fclose(malf); not here bozo */
unlock();
return(1);
Notice how the file is opened for appending BEFORE being locked.
This presents a race condition where several mail's all open the
file for appending (all using the current length of the file)
then take turns locking the file overwriting each other.
The fix of course is to move the lock() above the fopen and add a
unlock() if you can't open the file.
---> lock(file); /* Bug fix. sequel!phil */
mask = umask(MAILMODE);
---> malf = fopen(file, "a");
umask(mask);
if (malf == NULL) {
unlock(); /* Bug fix. see above */
fprintf(stdout, "mail: cannot append to %s\n", file);
return(0);
}
/* lock(file); not early enough */
chown(file, pw->pw_uid, pw->pw_gid);
{
f = open("/dev/mail", 1);
sprintf(buf, "%s@%d\n", name, ftell(malf));
}
copylet(n, malf, ORDINARY);
fclose(malf); /* here so comsat works! */
if (f >= 0) {
write(f, buf, strlen(buf)+1);
close(f);
}
/* fclose(malf); not here bozo */
unlock();
return(1);
After this fix, my test ran 10 times without a fail. If you are
concerned about your mail you should fix this one. I don't know
if someone else already posted this bug but I have never seen it.
I don't have a copy of V7 /bin/mail handy but I suspect it exists
there also.
Phil Hochstetler
Sequel Computer Systems, Inc.
Portland, Oregon
(503) 626-5700
uucp: ogcvax!sequel!phil
pur-ee!sequel!phil
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site sequel.UUCP
Path: utzoo!linus!genrad!grkermit!mit-vax!eagle!harpo!floyd!vax135!cornell!uw-beaver!tektronix!ogcvax!sequel!phil
From: p...@sequel.UUCP
Newsgroups: net.bugs.4bsd
Subject: Nasty 4.1c bug
Message-ID: <181@sequel.UUCP>
Date: Mon, 20-Jun-83 13:14:02 EDT
Article-I.D.: sequel.181
Posted: Mon Jun 20 13:14:02 1983
Date-Received: Sun, 26-Jun-83 18:39:23 EDT
Organization: Sequel Computer Systems, Portland
Lines: 42
Be very careful with the shell script "vipw" under 4.1c. It can
and will wipe out your passwd file. A problem occurs if someone
runs the passwd command while you are running vipw. The next
time you run vipw, you zero out the passwd file. Yes, you hear
me right.
The problem is in how vipw and passwd(1) lock the passwd file.
If you glance at vipw, you will notice it creates /etc/vipw.lock
by copying /dev/null to it. It trys to link to this file and
create /etc/ptmp since this is the file used to lock the passwd
file. If this link fails then someone is changing their passwd
and the passwd file is busy. This is cool.
The problem is when this succeeds and you are busy editing the
passwd file and someone decides to change their passwd. The
passwd command in 4.1c just does a fancy open with the options to
set an advisary lock. This does not take into account the file
may already exist! It then copys the passwd file into this
supposed safe tmp file and renames this file as /etc/passwd
(remember you still have a link to it called vipw.lock).
You probably smell a rat by now. Your only indication that
something is amiss is that vipw complains about not being able to
remove /etc/ptmp. Humm. The next time you run vipw it promptly
copys /dev/null to vipw.lock which just happens to be linked to
/etc/passwd. Goodbye passwd file. This happend to us. Really
nasty problem. As a side issue, we crashed 10 seconds later.
The 4.1 passwd command uses the access() call to determine the
passwd file is busy (/etc/ptmp exists) and exits printing a
message about the passwd file being busy. I am not sure why the
locking stuff was changed since access() still exists. I think
we are going to change vipw to a C program that obeys the
convention of advisary locks (the other fix is to use the old
passwd command or use the access() call).
Phil Hochstetler (503) 626-5700
Sequel Computer Systems, Inc.
Portland, Oregon
uucp: ogcvax!sequel!phil
pur-ee!sequel!phil
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site sequel.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!vax135!cornell!uw-beaver!tektronix!ogcvax!sequel!rbk
From: r...@sequel.UUCP
Newsgroups: net.unix-wizards
Subject: 4.1c Ether Addressing Problem
Message-ID: <188@sequel.UUCP>
Date: Thu, 23-Jun-83 12:20:48 EDT
Article-I.D.: sequel.188
Posted: Thu Jun 23 12:20:48 1983
Date-Received: Mon, 27-Jun-83 21:56:10 EDT
Organization: Sequel Computer Systems, Portland
Lines: 25
The manual pages for 4.1c ethernet drivers specify that they fill in
the 48-bit destination field in the packet with their *own* high-order
3-bytes, and 3-bytes of (low-order) destination address. The sources
are consistent with this. This seems to imply that all the ethernet
boards in your collection of systems must come from the same
manufacturer, unless you have gateway(s). This is an undesireable
restriction.
Is this an accurate description of the problem? It seems that the inet
code uses "struct sockaddr_in" to indicate addresses, and this contains
a "struct in_addr" which uses a single (unsigned) long to store the
address. There are comments that suggest this is "old style" inter-net
addresses.
Hence the questions: is this problem going to be fixed in 4.2? If
not, does anyone have ideas on how to fix it? My fear is that changes
might propogate throughout the TCP/IP code, due to the unusual size of
the necessary addresses.
--
Bob Beck
Sequel Computer Systems
...ogcvax!sequel!rbk
(503)627-9809
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site sequel.UUCP
Path: utzoo!linus!decvax!tektronix!ogcvax!sequel!phil
From: p...@sequel.UUCP
Newsgroups: net.unix
Subject: Re: UNIX 4.1 <--> 4.2
Message-ID: <279@sequel.UUCP>
Date: Thu, 6-Oct-83 12:57:58 EDT
Article-I.D.: sequel.279
Posted: Thu Oct 6 12:57:58 1983
Date-Received: Sat, 8-Oct-83 04:55:41 EDT
References: <12187@sri-arpa.UUCP> <38@astrovax.UUCP>
Organization: Sequel Computer Systems, Portland
Lines: 7
Rest assured that 4.2 BSD is real! Our box of tapes and MONDO
documentation showed up Fed-X yesterday. Say good bye to 4.1C.
--
Phil Hochstetler (503) 627-9811
Sequel Computer Systems
...!sequel!phil
|