Messages in this thread |  | | Date | Sat, 6 Mar 2010 01:20:09 +0100 | From | Lennart Poettering <> | Subject | Re: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for child processes |
| |
On Thu, 04.03.10 14:14, Roland McGrath (roland@redhat.com) wrote:
> There are a few different aspects of behavior change to think about. > > 1. Who can get a SIGCHLD and wait result they weren't expecting. > 2. Who sees some PID for getppid() when they are expecting 1. > 3. What ps shows. > > When I start thinking through what might be security issues, they are > almost all #1 questions. There is a hairy nest of many variations of #1 > questions. The #2 question is pretty simple, but it also could be an issue > for security when setuid is involved (or just correctness for any > application). > > My impression is that #3 is the only actual motivation for this feature. > So perhaps we should consider an approach that leaves the rest of the > semantics alone and only affects that. > > Lennart, am I right that this is all you are looking for? Does it even > matter to you that this change the PPID that ps groks today? How about if > it's just an entirely new kind of assocation that ps et al can learn to > display, and not even the traditional PPID field changes?
Uh, no. Actually it's the fact that my sub-init gets the SIGCHLD, which I am looking for. The clean ps tree is just a side-effect.
When the sub-init gets the SIGCHLD for its "grandchildren" then we can supervise double-forking daemons, and properly handle daemons that die due to SIGSEGV and suchlike.
So what I am after is the SIGCHLD for the grandparents, the clean ps tree is kinda boring.
Lennart
-- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
|  |