Messages in this thread | | | From | (Eric W. Biederman) | Date | Mon, 10 Dec 2018 11:36:59 -0600 | Subject | Re: siginfo pid not populated from ptrace? |
| |
Oleg Nesterov <oleg@redhat.com> writes:
> On 12/06, Eric W. Biederman wrote: >> >> The challenge is that we could be delivering this to a zombie signal >> group leader. > > ... > >> Sigh it is probably time that I dig in and figure out how to avoid that >> case which we need to fix anyway because we can get the permission >> checks wrong for multi-threaded processes that call setuid and friends. > > this is another issue... I am sure we have already discussed this, but I > failed to find any link to the previous discussion.
Now that we have PIDTYPE_TGID I think we are closer to being able to solve that issue. You are absolutely right it is another issue.
>> Once that is sorted your small change will at least be safe. > > I don't think so, any sub-thread can dequeue SIGSTOP unless type == PIDTYPE_PID, > this has nothing to do with the problems connected to zombie leader, or I > misunderstood you.
I forgot to check what wants_signal does in this case. I thought SIGSTOP was like SIGKILL and being unblockable would always be delivered to the thread we are aiming at. With a zombie leader being the exception.
Having reread wants_signal you are absolutely correct. SIGSTOP can be delivered to any thread so this won't help. I don't understand why for SIGSTOP we don't treat SIGSTOP like SIGKILL, but that is also another conversation. It feels like the differences between SIGSTOP and SIGKILL in wants_signal are silly. I don't see them leading to incorrect behavior.
Eric
| |