daveb@llama.rtech.UUCP (Dave Brower) (12/03/87)
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?
Thanks,
-dB
"I don't care what you say, as long as you spell my name right."
{amdahl, cbosgd, mtxinu, ptsfa, sun}!rtech!daveb daveb@rtech.uucpmwp@munnari.UUCP (12/04/87)
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?"