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

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 23 Dec 2010 16:00:54 +0000
From:	Scott James Remnant <scott@...split.com>
To:	Lennart Poettering <mzxreary@...inter.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] exit: PR_SET_ANCHOR for marking processes as reapers for
 child processes

On Thu, Dec 23, 2010 at 3:44 PM, Lennart Poettering
<mzxreary@...inter.de> wrote:
> On Tue, 21.12.10 12:05, Scott James Remnant (scott@...split.com) wrote:
>
>> > PID namespaces primarily provide an independent PID numbering scheme for
>> > a subset of processes, i.e. so that identical may PIDs refer to different
>> > processes depending on the namespace they are running in. As a side
>> > effect this also provides init-like behaviour for processes that aren't
>> > the original PID 1 of the operating system. For systemd we are only
>> > interested in this side effect, but are not interested at all in the
>> > renumbering of processes, and in fact would even really dislike if it
>> > happened. That's why PR_SET_ANCHOR is useful: it gives us init-like
>> > behaviour without renaming all processes.
>> >
>> Right, but I don't get why you need this behavior to supervise either
>> system or user processes.  You already get all the functionality you
>> need to track processes via either cgroups or the proc connector (or a
>> combination of both).
>
> Well, we want a clean way to get access to the full siginfo_t of the
> SIGCHLD for the main process of a service. the proc connector is awful
> and cgroups does not pass siginfo_t's back to userspace, hence the
> cleanest way to get this done properly and beautifully is to make the
> session systemd a mini-init via PR_SET_ANCHOR, because then the per-user
> systemd's and the per-system systemd can use the exact same code to
> handle process managment.
>
Ah, if you're after the siginfo_t this makes more sense.

You may or may not be interested in a patch I did a couple of years
ago, this also spliced into the same kind of code, but to notify init
via signal when it got given a new process via adoption.  I assume
this would work with a PR_SET_ANCHOR'd mini-init too?

(Apologies if the attachment screws up, still getting used to gmail :p)

Scott

View attachment "notify-adoption-simple.patch" of type "text/x-patch" (5654 bytes)