Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Wed, 13 Mar 2019 10:10:03 +0100
From:   Christian Brauner <christian@brauner.io>
To:     Jonathon Kowalski <bl0pbl33p@gmail.com>
Cc:     torvalds@linux-foundation.org, arnd@arndb.de,
        linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linuxtronix.de
Subject: Re: [GIT PULL RESEND] pidfd changes for v5.1-rc1
Message-ID: <20190313091001.6a3wzh6evpe4hxdn@brauner.io>
References: <d5a0a45e-77c3-afc7-fed2-8453d8e95bb4@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <d5a0a45e-77c3-afc7-fed2-8453d8e95bb4@gmail.com>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Mar 13, 2019 at 05:00:57AM +0000, Jonathon Kowalski wrote:
> Hi,
> 
> Thanks for the work on this system call! I am interested in making use of it
> in my process supervisor. It works pretty well and avoids the long-standing
> issue of PID reuse.

Thanks! The systemd folks have been quite excited about this too.

> 
> One thing that instantly came to mind is to be able to delegate killing to
> some third process depending on the confguration. However, I don't see that
> permissions are attached to the open file description, but seemed to be
> checked when calling pidfd_send_signal as they are with kill(2). Is there

It came up during the discussion. We all preferred to have something
simple and not introduce a new permission model.

There's nothing necessarily blocking us from doing this in the future
though. It's not off the table but out of scope for now.

Thanks!
Christian