From owner-freebsd-hackers Wed Apr 29 05:38:42 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA18037 for freebsd-hackers-outgoing; Wed, 29 Apr 1998 05:38:42 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA18018; Wed, 29 Apr 1998 05:38:36 -0700 (PDT) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id HAA16057; Wed, 29 Apr 1998 07:38:26 -0500 (CDT) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id HAA06012; Wed, 29 Apr 1998 07:38:26 -0500 (CDT) Message-ID: <19980429073826.29484@mcs.net> Date: Wed, 29 Apr 1998 07:38:26 -0500 From: Karl Denninger To: Eivind Eklund Cc: Jason Nordwick , dyson@FreeBSD.ORG, Robert Withrow , freebsd-hackers@FreeBSD.ORG Subject: Re: SIGDANGER References: <199804280030.UAA06099@spooky.rwwa.com> <199804280453.XAA03316@dyson.iquest.net> <19980428073841.05698@mcs.net> <19980428192742.1224.qmail@xcf.berkeley.edu> <19980428143114.33662@mcs.net> <19980429063246.07285@follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: <19980429063246.07285@follo.net>; from Eivind Eklund on Wed, Apr 29, 1998 at 06:32:46AM +0200 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Apr 29, 1998 at 06:32:46AM +0200, Eivind Eklund wrote: > On Tue, Apr 28, 1998 at 02:31:14PM -0500, Karl Denninger wrote: > > [... types of SIGDANGER handling...] > > This leaves you with: > > > > 1) Do nothing - you get the semantics we have now. If the kernel > > needs to whack you it will, without notice, but the warning > > is ignored (you don't want to do anything with it). > > > > 2) Trap the signal - you get notice, and can clean up and exit if you > > are able. You're still vulnerable, in that the kernel can whack > > you if it needs to (and you're still around). The kernel can put > > these processes into the "second round" bucket - it at least knows > > that you're trying to help. > > > > 3) Set SIG_HOLD. You're a critical process and the kernel should go > > pick on someone else if it can. If it can't, well, tough bananas, > > but at least we tried to keep you going. > > We should distinguish between user processes and root processes > somehow, too. A user shouldn't be able to make root's processes die > unless the machine is explictly configured for that to be possible > (IMO). > > Eivind. Simple. sysctl variable for whether or not a user process can set SIG_HOLD. If not, then a user process cannot cause a critical system process to die. If you want to get fancy, then a second sysctl variable which controls whether there exists another bucket for root processes, which go between (2) and (3) (creating really four buckets - user processes which do nothing, user processes which trap SIGDANGER, root processes which do nothing, and any process which has set SIG_HOLD). This does require that critical system processes have a SIGDANGER handler added. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message