Messages in this thread | | | Date | Tue, 20 Oct 2015 19:36:36 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 0/2] wait/ptrace: always assume __WALL if the child is traced |
| |
Forgot to say...
Another question is why PTRACE_TRACEME succeeds in this case. I guess it is to late to change (break) the rules, but I never understood the security checks. The comment above cap_ptrace_traceme() says:
Determine whether another process may trace the current
and "another process" is parent. To me this looks strange, imo we should determine whether the current may abuse its parent. So perhaps we could change ptrace_traceme() to fail if
current->parent_exec_id != parent->self_exec_id
?
But this too can break something. Although I can't imagine why the child reaper or a PR_SET_CHILD_SUBREAPER process may want to trace the reparented tasks.
On 10/20, Oleg Nesterov wrote: > > Damn. I simply do not know what should/can we do. From the change > log: > > And I can only hope that this won't break something. > > yet this patch cc's -stable. > > > Please see the changelog, but in short: this is not a kernel bug > but unlikely we can fix all distributions, so I think we have to > change the kernel. > > HOWEVER. With this change __WCLONE and __WALL have no effect for > debugger, do_wait() works as if __WALL is set if the child (natural > or not) is traced. > > > Jan, Pedro, could you please confirm this won't break gdb? I tried > to look into gdb-7.1, and at first glance gdb uses __WCLONE only > because __WALL doesn't work on older kernels, iow it seems to me > that gdb actually wants __WALL so this change should be fine. > > > Any other ideas? > > Oleg.
| |