Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Thu, 2017-10-05 at 18:27 +0200, Oleg Nesterov wrote: >> On 10/03, Jürg Billeter wrote: >> > >> > My use case is to provide a way for a process to spawn a child and >> > ensure that no descendants survive when that child dies. Avoiding >> > runaway

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Thu, 2017-10-05 at 18:27 +0200, Oleg Nesterov wrote: >> On 10/03, Jürg Billeter wrote: >> > >> > My use case is to provide a way for a process to spawn a child and >> > ensure that no descendants survive when that child dies. Avoiding >> > runaway processes is

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Thu, 2017-10-05 at 18:27 +0200, Oleg Nesterov wrote: > On 10/03, Jürg Billeter wrote: > > > > My use case is to provide a way for a process to spawn a child and > > ensure that no descendants survive when that child dies. Avoiding > > runaway processes is desirable in many situations. My

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Thu, 2017-10-05 at 18:27 +0200, Oleg Nesterov wrote: > On 10/03, Jürg Billeter wrote: > > > > My use case is to provide a way for a process to spawn a child and > > ensure that no descendants survive when that child dies. Avoiding > > runaway processes is desirable in many situations. My

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On 10/03, Jürg Billeter wrote: > > My use case is to provide a way for a process to spawn a child and > ensure that no descendants survive when that child dies. Avoiding > runaway processes is desirable in many situations. My motivation is > very lightweight (nested) sandboxing (every process is

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On 10/03, Jürg Billeter wrote: > > My use case is to provide a way for a process to spawn a child and > ensure that no descendants survive when that child dies. Avoiding > runaway processes is desirable in many situations. My motivation is > very lightweight (nested) sandboxing (every process is

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Linus Torvalds writes: > On Tue, Oct 3, 2017 at 12:30 PM, Eric W. Biederman > wrote: >> >> We never signal the orignal parent. We signal the child that >> requested the pdeath_signal when the original parent dies. > > Yeah, I keep making

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Linus Torvalds writes: > On Tue, Oct 3, 2017 at 12:30 PM, Eric W. Biederman > wrote: >> >> We never signal the orignal parent. We signal the child that >> requested the pdeath_signal when the original parent dies. > > Yeah, I keep making that mistake, because I always confuse this with > the

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, Oct 3, 2017 at 12:30 PM, Eric W. Biederman wrote: > > We never signal the orignal parent. We signal the child that > requested the pdeath_signal when the original parent dies. Yeah, I keep making that mistake, because I always confuse this with the exit_signal

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, Oct 3, 2017 at 12:30 PM, Eric W. Biederman wrote: > > We never signal the orignal parent. We signal the child that > requested the pdeath_signal when the original parent dies. Yeah, I keep making that mistake, because I always confuse this with the exit_signal handling. Just mentally

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Linus Torvalds writes: > On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman > wrote: >> >> *Scratches head* >> pdeath_signal is cleared during exec if bprm->cap_elevated. > > It's not cleared if we are *releasing* capabilities, which is

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Linus Torvalds writes: > On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman > wrote: >> >> *Scratches head* >> pdeath_signal is cleared during exec if bprm->cap_elevated. > > It's not cleared if we are *releasing* capabilities, which is exactly > what might cause a "we can no longer send a

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Tue, 2017-10-03 at 12:40 -0500, Eric W. Biederman wrote: >> Jürg Billeter writes: >> > What's actually the reason that CLONE_NEWPID requires CAP_SYS_ADMIN? >> > Does CLONE_NEWPID pose any risks that don't exist for >> >

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Tue, 2017-10-03 at 12:40 -0500, Eric W. Biederman wrote: >> Jürg Billeter writes: >> > What's actually the reason that CLONE_NEWPID requires CAP_SYS_ADMIN? >> > Does CLONE_NEWPID pose any risks that don't exist for >> > CLONE_NEWUSER|CLONE_NEWPID? Assuming we can't

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, 2017-10-03 at 12:40 -0500, Eric W. Biederman wrote: > Jürg Billeter writes: > > What's actually the reason that CLONE_NEWPID requires CAP_SYS_ADMIN? > > Does CLONE_NEWPID pose any risks that don't exist for > > CLONE_NEWUSER|CLONE_NEWPID? Assuming we can't simply drop

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, 2017-10-03 at 12:40 -0500, Eric W. Biederman wrote: > Jürg Billeter writes: > > What's actually the reason that CLONE_NEWPID requires CAP_SYS_ADMIN? > > Does CLONE_NEWPID pose any risks that don't exist for > > CLONE_NEWUSER|CLONE_NEWPID? Assuming we can't simply drop the > >

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Tue, 2017-10-03 at 09:46 -0500, Eric W. Biederman wrote: >> There is a general need to find out about the death of other processes, >> if you are not the parent of the process. I would be inclined to call >> it waitfd. Something that you give a pid.

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Tue, 2017-10-03 at 09:46 -0500, Eric W. Biederman wrote: >> There is a general need to find out about the death of other processes, >> if you are not the parent of the process. I would be inclined to call >> it waitfd. Something that you give a pid. It performs a

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman wrote: > > *Scratches head* > pdeath_signal is cleared during exec if bprm->cap_elevated. It's not cleared if we are *releasing* capabilities, which is exactly what might cause a "we can no longer send a signal" > is_setid

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, Oct 3, 2017 at 9:36 AM, Eric W. Biederman wrote: > > *Scratches head* > pdeath_signal is cleared during exec if bprm->cap_elevated. It's not cleared if we are *releasing* capabilities, which is exactly what might cause a "we can no longer send a signal" > is_setid is set if the uid !=

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, 2017-10-03 at 09:46 -0500, Eric W. Biederman wrote: > There is a general need to find out about the death of other processes, > if you are not the parent of the process. I would be inclined to call > it waitfd. Something that you give a pid. It performs a permission > check and the pid

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, 2017-10-03 at 09:46 -0500, Eric W. Biederman wrote: > There is a general need to find out about the death of other processes, > if you are not the parent of the process. I would be inclined to call > it waitfd. Something that you give a pid. It performs a permission > check and the pid

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Linus Torvalds writes: > On Tue, Oct 3, 2017 at 7:46 AM, Eric W. Biederman > wrote: >> >> The process that requests the signal be sent is the process that is >> receiving the signal. I can see a theoretical need for a permission >> check

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Linus Torvalds writes: > On Tue, Oct 3, 2017 at 7:46 AM, Eric W. Biederman > wrote: >> >> The process that requests the signal be sent is the process that is >> receiving the signal. I can see a theoretical need for a permission >> check in there somewhere (especially as this persists over

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, Oct 3, 2017 at 7:46 AM, Eric W. Biederman wrote: > > The process that requests the signal be sent is the process that is > receiving the signal. I can see a theoretical need for a permission > check in there somewhere (especially as this persists over fork). Note

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Tue, Oct 3, 2017 at 7:46 AM, Eric W. Biederman wrote: > > The process that requests the signal be sent is the process that is > receiving the signal. I can see a theoretical need for a permission > check in there somewhere (especially as this persists over fork). Note that it also persists

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Mon, 2017-10-02 at 22:25 -0500, Eric W. Biederman wrote: >> The code where it calls group_send_sig_info is buggy for pdeath_signal. >> And it no less buggy for this new case. There is no point to check >> permissions when sending a signal to yourself.

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Jürg Billeter writes: > On Mon, 2017-10-02 at 22:25 -0500, Eric W. Biederman wrote: >> The code where it calls group_send_sig_info is buggy for pdeath_signal. >> And it no less buggy for this new case. There is no point to check >> permissions when sending a signal to yourself. Especially this

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Mon, 2017-10-02 at 22:25 -0500, Eric W. Biederman wrote: > The code where it calls group_send_sig_info is buggy for pdeath_signal. > And it no less buggy for this new case. There is no point to check > permissions when sending a signal to yourself. Especially this signal > gets cleared during

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Mon, 2017-10-02 at 22:25 -0500, Eric W. Biederman wrote: > The code where it calls group_send_sig_info is buggy for pdeath_signal. > And it no less buggy for this new case. There is no point to check > permissions when sending a signal to yourself. Especially this signal > gets cleared during

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Andrew Morton writes: > On Fri, 29 Sep 2017 14:30:58 +0200 Jürg Billeter wrote: > >> PR_SET_PDEATHSIG sets a parent death signal that the calling process >> will get when its parent thread dies, even when the result of getppid() >> doesn't change

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

Andrew Morton writes: > On Fri, 29 Sep 2017 14:30:58 +0200 Jürg Billeter wrote: > >> PR_SET_PDEATHSIG sets a parent death signal that the calling process >> will get when its parent thread dies, even when the result of getppid() >> doesn't change because the calling process is reparented to a

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Fri, 29 Sep 2017 14:30:58 +0200 Jürg Billeter wrote: > PR_SET_PDEATHSIG sets a parent death signal that the calling process > will get when its parent thread dies, even when the result of getppid() > doesn't change because the calling process is reparented to a different >

Re: [RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

On Fri, 29 Sep 2017 14:30:58 +0200 Jürg Billeter wrote: > PR_SET_PDEATHSIG sets a parent death signal that the calling process > will get when its parent thread dies, even when the result of getppid() > doesn't change because the calling process is reparented to a different > thread in the same

[RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

PR_SET_PDEATHSIG sets a parent death signal that the calling process will get when its parent thread dies, even when the result of getppid() doesn't change because the calling process is reparented to a different thread in the same parent process. When managing multiple processes, a process-based

[RESEND PATCH] prctl: add PR_[GS]ET_PDEATHSIG_PROC

PR_SET_PDEATHSIG sets a parent death signal that the calling process will get when its parent thread dies, even when the result of getppid() doesn't change because the calling process is reparented to a different thread in the same parent process. When managing multiple processes, a process-based