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?"