mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jonathon Kowalski <bl0pbl33p@gmail.com>
To: christian@brauner.io
Cc: torvalds@linux-foundation.org, arnd@arndb.de,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	tglx@linuxtronix.de
Subject: [GIT PULL RESEND] pidfd changes for v5.1-rc1
Date: Wed, 13 Mar 2019 05:00:57 +0000	[thread overview]
Message-ID: <d5a0a45e-77c3-afc7-fed2-8453d8e95bb4@gmail.com> (raw)
In-Reply-To: 

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

             reply	other threads:[~2019-03-13  5:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13  5:00 Jonathon Kowalski [this message]
2019-03-13  9:10 ` Christian Brauner
  -- strict thread matches above, loose matches on Subject: below --
2019-03-12 13:52 Christian Brauner
2019-03-16  1:22 ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d5a0a45e-77c3-afc7-fed2-8453d8e95bb4@gmail.com \
    --to=bl0pbl33p@gmail.com \
    --cc=arnd@arndb.de \
    --cc=christian@brauner.io \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linuxtronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®