Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 8/7/84; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!ucbvax!anton From: anton@ucbvax.ARPA (Jeff Anton) Newsgroups: net.bugs.v7,net.unix-wizards Subject: Re: unexpected alarms Message-ID: <4128@ucbvax.ARPA> Date: Thu, 10-Jan-85 14:55:14 EST Article-I.D.: ucbvax.4128 Posted: Thu Jan 10 14:55:14 1985 Date-Received: Sat, 12-Jan-85 01:39:08 EST References: <4861@utzoo.UUCP> <4889@utzoo.UUCP> Reply-To: anton@ucbvax.UUCP (Jeff anton) Organization: University of California at Berkeley Lines: 30 Xref: watmath net.bugs.v7:184 net.unix-wizards:11448 Summary: In article <4889@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >Does anybody know of any case where the persistence of alarms across >exec is genuinely useful? I personally think that just cancelling >them altogether is the right thing to do. My kernel mod cancels them >only for setuid/gid programs simply because this was the minimum change >in behavior needed to make things safe. I have used the persistence of the alarm signal in a debatably useful mannor. I've a graphics program for the SUN workstation that runs until interuption that I use in my .logout file. In that file a command that checks if I'm on the console and if so, sets an alarm for a minute and then execs my graphics. I did not have to modifiy my program to have a "time to die" option. I'd like to keep the persistent alarm for that case. I've written a general process supervisor that kills programs if the load goes to high or if it runs too long. I think the persistant alarms would be an easy way to limit program execution time. Aside from the above, I think cancelling alarms across execs of set[ug]id file would be a safer thing to do. And, in the future, setid programs should be written with the alarm signal in mind. (Actually every signal should be considered where writeing these programs. One never knows.) ___________ C knows no bounds. Jeff Anton U.C. Berkeley ucbvax!anton anton@berkeley.ARPA