Re: [PATCH RFC v3 2/4] pidfd: add CLONE_PIDFD_AUTOKILL

[Christian Brauner <brauner@kernel.org>]

On Tue, Feb 17, 2026 at 03:44:52PM -0800, Linus Torvalds wrote:
> On Tue, 17 Feb 2026 at 15:38, Jann Horn <jannh@google.com> wrote:
> >
> > You can already send SIGHUP to such binaries through things like job
> > control, right?
> 
> But at least those can be blocked, and people can disassociate
> themselves from a tty if they care etc.
> 
> This seems like it can't be blocked any way, although I guess you can
> just do the double fork dance to distance yourself from your parent.
> 
> > Also, on a Linux system with systemd, I believe a normal user, when
> > running in the context of a user session (but not when running in the
> > context of a system service), can already SIGKILL anything they launch
> > by launching it in a systemd user service, then doing something [...]
> 
> Ugh. But at least it's not the kernel that does it, and we have rules
> for sending signals.
> 
> > I agree that this would be a change to the security model, but I'm not
> > sure if it would be that big a change.
> 
> I would expect most normal binaries to expect to be killed with ^C etc
> anyway, so in that sense this is indeed likely not a big deal. But at
> least those are well-known and traditional ways of getting signals
> that people kind of expecy.

I think you missed the message that I sent as a reply right away.

I'm very aware that as written this will allow users to kill setuid
binaries. I explictly wrote the first RFC so autokill isn't reset during
bprm->secureexec nor during commit_creds() - in contrast to pdeath
signal. I'm very aware of all of this and am calling it out in the
commit message as well.

The kill-on-close contract cannot be flaunted no matter what gets
executed very much in contrast to pdeath_signal which is annoying
because it magically gets unset and then userspace needs to know when it
got unset and then needs to reset it again.

My ideal model for kill-on-close is to just ruthlessly enforce that the
kernel murders anything once the file is released. I would value input
under what circumstances we could make this work without having the
kernel magically unset it under magical circumstances that are
completely opaque to userspace.