Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Apr 1998 07:38:26 -0500
From:      Karl Denninger  <karl@mcs.net>
To:        Eivind Eklund <eivind@yes.no>
Cc:        Jason Nordwick <nordwick@scam.XCF.Berkeley.EDU>, dyson@FreeBSD.ORG, Robert Withrow <witr@rwwa.com>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: SIGDANGER
Message-ID:  <19980429073826.29484@mcs.net>
In-Reply-To: <19980429063246.07285@follo.net>; from Eivind Eklund on Wed, Apr 29, 1998 at 06:32:46AM %2B0200
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980429073826.29484>