lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 Jan 2017 17:44:20 +0100
From:   Oleg Nesterov <>
To:     Pavel Tikhomirov <>,
        "Eric W. Biederman" <>,
        Lennart Poettering <>,
        Kay Sievers <>
Cc:     Ingo Molnar <>,
        Peter Zijlstra <>,
        Andrew Morton <>,
        Cyrill Gorcunov <>,
        John Stultz <>,
        Thomas Gleixner <>,
        Nicolas Pitre <>,
        Michal Hocko <>,
        Stanislav Kinsburskiy <>,
        Mateusz Guzik <>,,
        Pavel Emelyanov <>,
        Konstantin Khorenko <>
Subject: setns() && PR_SET_CHILD_SUBREAPER

And this discussion reminds me again that I do not understand how setns()
and PR_SET_CHILD_SUBREAPER should play together... Add cc's.

Suppose we have a process P in the root namespace and another namespace X.

P does setns() and enters the X namespace.
P forks a child C.

C forks a grandchild G.
C exits.

The question is, where should we reparent the grandchild G? In the normal
case it will be reparented to X->child_reaper and this looks correct.

But lets suppose that P runs with the ->has_child_subreaper bit set. In
this case it will be reparented to P's sub-reaper or a global init, and
given that P can't control its ->has_child_subreaper flag this does not
look right to me.

I can make a simple patch but perhaps I missed something or we actually
want this (imo strange) behaviour?


Powered by blists - more mailing lists