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.
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 any particular reason this was avoided? For instance,
if a process with CAP_KILL opens the procfd, shouldn't any process that
uses a descriptor pointing to this same file description be permitted to
send signals? It would be a lot more useful that way.
There doesn't seem to much benefit of using file descriptors for
processes otherwise if cannot use them that way, apart from PID reuse.
So, is something like this on the roadmap in the future, and if not,
what was the reason it was avoided? I don't see a problem with using
CAP_KILL to not check permissions at call time, otherwise I can see why
it would be a problem in general (because processes can change credentials).
Regards,
Jonathon Kowalski
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