unexpected alarms

[Geoff Kuenning]

In article <4861 at utzoo.UUCP> henry at 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