unexpected alarms

[Henry Spencer]

There is a destructive security bug in almost every existing Unix version.
Try writing a program that sets an alarm and then execs, say, passwd(1).
A few seconds later, passwd(1) gets the alarm and drops dead, perhaps in
the middle of an update to /etc/passwd.

This problem definitely exists in V7.  Inspection of source indicates
that it probably exists in System V.  (We have, but do not run, SysV.)
I haven't summoned up the courage to check 4.2.

Clearly, the *wrong* thing to do is to require every setuid program
to reset the alarm.  People writing setuid programs have enough to worry
about already.  There is also an important corollary of the Law of Least
Astonishment:  if you don't use a facility, you shouldn't have to care
about it.

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.

In V7 (SysV is similar, dunno about Berklix), late in sys1.c/getxfile(),
you will find the code that implements setuid.  It's trivial to add the
statement:

	u.u_procp->p_clktim = 0;

to the uid-setting and gid-setting if's.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry