root@convex.UUCP (12/12/84)
Steve is correct. Additionally, there was another smtpquit with the wrong number of arguments in usersmtp.c Moreso, in srvrsmtp.c, there is a call to parseaddr which omits the final argument (delimiter). I entered '\0' for it. The core dump problem seems to be gone now. Why didn't sendmail pass lint before it was distributed? Rk
nrh@faust.UUCP (01/08/86)
>/**** faust:net.bugs.4bsd / ki4pv!tanner / 10:09 am Dec 18, 1985 ****/ >] utzoo!henry points out problem of fool opening/locking /etc/passwd >] and claims that adding open("arg", O_READ|EXCL) re-invents flock() > >Doesn't re-invent flock() -- open()/flock() is not an atomic action. > >Security is easily solved by refusing to allow locking a file unless >the file has been successfully opened for WRITE -- there's no real >excuse for a read-only prog to need to lock a file if the write-file >prog successfully locks the damned thing anyway. >-- ><std dsclm, copies upon request> Tanner Andrews, KI4PV >uucp: ...!decvax!ucf-cs!ki4pv!tanner >/* ---------- */ Not to carry this on too long, but I believe Tanner Andrews is incorrect. Very often one wishes to "share-lock" a file, so as to ensure that it doesn't change while you read it. The idea here is that the file may be periodically updated by a master process and read by processes which should not be able to write the file, but which which must read it only when the file is in a "consistent" state. An example is a list of budget items, where the total cost is included in the master file. Change an item, and then read the file, and then change the total, and you'll find the total read by the reading process doesn't match the total of the items read by the reading process. Standard practice is for the reading processses to "share-lock" the file, read the items, read the total, and unlock the file. Standard practice for the writing process is to "exclusive-lock" the file, do the updates, and unlock. The reading process doesn't need exclusive locks (there might be many) but the writing process does. The reading process DOES need to guarantee that no updates happen among the reads. Hope this is clear (and correct!) - Nat Howard
nrh@inmet.UUCP (09/09/86)
>/* Written 2:58 pm Aug 20, 1986 by david@varian.UUCP in inmet:net.bugs.4bsd */ >/* ---------- "tip shell escape (4.3BSD)" ---------- */ >I've been having problems using tip on 4.3BSD. When I try to use any >tilde command that requires forking a shell (~!, ~$, etc.), I get: > > /bin/csh: permission denied > >My environment variable SHELL is set to /bin/csh; when I change this >to /bin/sh, the subshell mechanism works. I've temporarily removed >my .cshrc file; this didn't help. I've looked at the code >where the fork and execl() are done (/usr/src/usr.bin/tip/cmds.c) and >don't see anything unusual. > >The permissions on /bin/csh look normal (755). The problem is due to the new version of csh being picky about effective uid not being equal to real uid. In one sense, this is exactly right -- the child of a tip fork should set its euid equal to its real uid just after the fork -- but it's a little odd that the shell should be the one to find this error. Doing this appears to cause some other problems (your "tip" session stops spontaneously after you exit the shell), but I haven't gotten around to looking at that yet. Here are the changes: *** /tmp/,RCSt1008084 Tue Sep 9 13:59:07 1986 --- cmds.c Tue Sep 9 13:41:26 1986 *************** *** 547,552 cp = value(SHELL); else cp++; execl(value(SHELL), cp, 0); printf("\r\ncan't execl!\r\n"); exit(1); --- 547,555 ----- cp = value(SHELL); else cp++; + + setuid(getuid()); /* Avoid "permission denied" problem */ + setgid(getgid()); /* ditto? */ execl(value(SHELL), cp, 0); printf("\r\ncan't execl!\r\n"); exit(1);