exit: PR_SET_ANCHOR for marking processes as reapers for child processes
in [Kernel]
|
Prev: [PATCH tip/core/rcu 2/3] rcu: Increase RCU CPU stall timeouts if PROVE_RCU
Next: exit: PR_SET_ANCHOR for marking processes as reapers for child processes
From: Lennart Poettering on 5 Mar 2010 19:20 On Thu, 04.03.10 15:08, Oleg Nesterov (oleg(a)redhat.com) wrote: > Should we clear ->child_anchor flags when the "sub-init" execs? Or, > at least, when the task changes its credentials? Probably not, but > dunno. Since this flag is only useful for a very well defined type of processes (i.e. session managers, supervising daemons, init systems) it might make sense to reset it automatically when privs are dropped or we exec something. After all, I don't see how we'd gain any useful functionality when we allow this flag to continue to be set. However we would certainly be on the safer side when we reset it, because that way it can never leak it to processes that are differently privileged or do not expect it. So, for the sake of being on the safe side, I think we should reset the flag on exec()/setuid(). > It is a bit strange that PR_SET_ANCHOR acts per-thread, not per > process. Yes, I agree, this should be per-process indeed. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Lennart Poettering on 5 Mar 2010 19:30 On Thu, 04.03.10 14:14, Roland McGrath (roland(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Roland McGrath on 8 Mar 2010 18:20
> 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. Ok. In that case, there is a substantial can of worms in considering compatibility breakages, and especially the various wrinkles of setuid that could be security issues. It will take a lot of careful thought to be sure how we can do this without opening new ways to confuse and abuse a setuid program. Thanks, Roland -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |