Messages in this thread | | | From | KOSAKI Motohiro <> | Subject | Re: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for child processes | Date | Fri, 5 Mar 2010 13:47:08 +0900 (JST) |
| |
> On 02/02, Lennart Poettering wrote: > > > > This patch adds a simple flag for each process that marks it as an > > "anchor" process for all its children and grandchildren. If a child of > > such an anchor dies all its children will not be reparented to init, but > > instead to this anchor, escaping this anchor process is not possible. A > > task with this flag set hence acts is little "sub-init". > > Lennart, this patch adds a noticeable linux-only feature. I see > your point, but imho your idea needs the "strong" acks. I cc'ed > some heavyweights, if someone dislikes your idea he can nack it > right now. > > > Security. This is beyond my understanding, hopefully the cc'ed > experts can help. > > Should we clear ->child_anchor flags when the "sub-init" execs? Or, > at least, when the task changes its credentials? Probably not, but > dunno. > > The more problematic case is when the descendant of the "sub-init" > execs the setuid application. Should we allow the reparenting to > !/sbin/init task in this case? > > Should we clear ->pdeath_signal after reparenting to sub-init ? > > Do we need the new security_operations->task_reparent() method ? > Or, perhaps we can reuse ->task_wait() if we add the "parent" > argument? > > Something else we should think about?
I think changing reparent rule is a bit risky. instead, I propse that exporting ANCHOR flag via /proc and ps parse it.
What do you think?
| |