Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1283340 > unrolled thread

Re: Unkillable processes due to PTRACE_TRACEME

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Unkillable processes due to PTRACE_TRACEME Pavel Machek <pavel@ucw.cz> - 2015-12-03 22:00 +0100
    Re: Unkillable processes due to PTRACE_TRACEME Oleg Nesterov <oleg@redhat.com> - 2015-12-04 20:10 +0100

#1283340 — Re: Unkillable processes due to PTRACE_TRACEME

Hi!

> > >> waitid(P_ALL, 0, {}, WNOHANG|WEXITED|WSTOPPED|WCONTINUED, NULL) = 0
> > >>
> > >> So what should be fixed here? Kernel of distro init?
> > >
> > > waitpid(__WALL) indeed joins these processes.
> 
> Thanks. And I just checked Fedora 22, it doesn't use __WALL too.
> 
> So I think we should change the kernel even if this is not a bug...
> I'll send the patch.
> 
> > > But __WALL can't be used with waitid and Ubuntu init uses waitid...
> 
> Yes, and I never understood why. Perhaps we should change this too.
> 
> > #include <pthread.h>
> > #include <unistd.h>
> > #include <sys/ptrace.h>
> > #include <stdio.h>
> > #include <errno.h>
> > #include <signal.h>
> > #include <sys/types.h>
> > #include <sys/wait.h>
> >
> > void *thr(void *arg) {
> >         ptrace(PTRACE_TRACEME, 0, 0, 0);
> >         return 0;
> > }
> >
> > int main() {
> > int pid = fork();
> >         if (pid == 0) {
> >                 pthread_t th;
> >                 pthread_create(&th, 0, thr, 0);
> >                 sleep(1);
> >                 return 0;
> >         }
> >         siginfo_t info = {};
> >         int status = 0;
> >         int res = waitpid(-1, &status, __WALL);
> >         printf("pid=%d res=%d errno=%d\n", pid, res, errno);
> >         res = waitpid(-1, &status, __WALL);
> >         printf("pid=%d res=%d errno=%d\n", pid, res, errno);
> >         return 0;
> > }
> >
> >
> > However, I need to wait for a particular child and if I change the
> > first waitpid to:
> >
> >         int res = waitpid(pid, &status, __WALL);
> >
> > then it does not terminate.
> > So how can I wait for such child process?
> 
> You can't. This is one of historical oddities. You need to reap the
> traced sub-thread first. And PTRACE_DETACH doesn't work.

If kill -9 does not take out the process, surely that sounds like a
security problem?

I know ptrace is old and tricky and ugly, but ....?

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1284164

Hi Pavel,

On 12/03, Pavel Machek wrote:
>
> > You can't. This is one of historical oddities. You need to reap the
> > traced sub-thread first. And PTRACE_DETACH doesn't work.
>
> If kill -9 does not take out the process,

Just in case, "kill -9" can't help because the task is already killed and
zombie. The problem is that /sbin/init can't reap it without __WALL unless
we change the kernel.

> surely that sounds like a
> security problem?
>
> I know ptrace is old and tricky and ugly, but ....?

Yes this should be fixed. I'll resend the patches next week, I am a bit busy
now.

And, Dmitry, I didn't forget about another problem you reported ;) I'll try
to redo/resend the fixes for WARN_ON() in in task_participate_group_stop()
as well.

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web