Re: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for child processes

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, Mar 4, 2010 at 20:47, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
>> 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?

No, that does not help anything, as mentioned earlier. It's not about
making 'ps' look nice, we need the signals if processes die, so we
want to be the parent of the process to keep the usual semantics.

Thanks,
Kay