[lkml]   [2010]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for child processes
    > 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?

     \ /
      Last update: 2010-03-05 05:49    [W:0.021 / U:5.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site