Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!sdcsvax!ucsdhub!esosun!seismo!uunet!munnari!mwp
From: mwp@munnari.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Why different kill(2) semantics?
Message-ID: <1921@munnari.oz>
Date: Thu, 3-Dec-87 21:45:25 EST
Article-I.D.: munnari.1921
Posted: Thu Dec  3 21:45:25 1987
Date-Received: Wed, 9-Dec-87 00:45:24 EST
References: <1454@rtech.UUCP>
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 34

in article <1454@rtech.UUCP>, daveb@llama.rtech.UUCP (Dave Brower) says:
> 
> On SV, non-root users may kill(2) processes having the same uid and
> their children.
> 
> On BSD, non-root users may only kill(2) processes having the same uid
> (modulo the setpgrp bug recently mentioned in this group.).  This makes
> it awkward to kill setuid subprocesses.
> 
> I notice that BSD vendors with ersatz SV wrappers usually keep this
> restriction.  Does anyone know _why_ this is desirable or necessary?  Is
> there some security problem that escapes me?

This is quite an annoying restriction at times, but a necessary one.
A setuid process (especially setuid to root) may be carrying out a
set of operations which may not be interrupted (eg. updating a database).
The System V solution, while much more convenient most of the time, can
cause serious problems and even be a security hole if the setuid process
is killed at *just* the right time.

You can always send tty generated signals to a child setuid process
in BSD, so all is not lost -- you can always turn off your terminal
if the process doesn't ignore SIGHUP. Perhaps SIGHUP should be made
a special case and be sendable to all child processes. A setuid
process can catch this and, if necessary, clean up before exitting.

					Michael Paddon
					==============

=========================================================
UUCP:		{seismo,mcvax,ukc,ubc-vision}!munnari!mwp
ARPA:		mwp%munnari.oz@seismo.css.gov
CSNET:		mwp%munnari.oz@australia
DISCLAIMER:	"Feathers or lead?"