Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/12/84; site desint.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxj!houxm!whuxlm!akgua!sdcsvax!sdcrdcf!trwrb!desint!geoff From: geoff@desint.UUCP (Geoff Kuenning) Newsgroups: net.bugs.v7,net.unix-wizards Subject: Re: unexpected alarms Message-ID: <293@desint.UUCP> Date: Mon, 7-Jan-85 22:41:09 EST Article-I.D.: desint.293 Posted: Mon Jan 7 22:41:09 1985 Date-Received: Fri, 11-Jan-85 23:42:23 EST References: <4861@utzoo.UUCP> Organization: his home computer, Manhattan Beach, CA Lines: 26 Xref: watmath net.bugs.v7:183 net.unix-wizards:11435 In article <4861@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >One can argue that alarms should not be allowed to persist across exec(2) >at all. This is probably stronger than necessary, however, and there are >a few uses for such persistence; see page 229 of Kernighan&Pike for an >example. However, not allowing alarms to persist across an exec of a >setuid (or setgid) program seems appropriate. Gee, the way I read the code (the description starts on 229, the code is on page 230), the alarm is indeed left on in the child, but this is a bug, not the way teh program was supposed to work. There should be an alarm(0) call just before the execvp call; the child will be killed with SIGKILL by the onalarm() routine. It seems to me that this type of code can handle any case where you want the effect of "leaving around" an alarm. After all, if you do SIGALRM instead of SIGKILL, the child process can't even tell the difference -- except that you can't do it if the kid is suid. I vote for setting u.u_procp->p_clktim to zero on all exec's, not just suid ones. I think this comes closer to the principle of "least astonishment" anyway. -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff