Messages in this thread | | | Date | Fri, 26 Mar 2010 05:46:19 -0700 | From | Matt Helsley <> | Subject | Re: Testing lxc 0.6.5 in Fedora 13 |
| |
On Fri, Mar 26, 2010 at 01:00:28PM +0100, Oleg Nesterov wrote: > On 03/26, Grzegorz Nosek wrote: > > > > On Fri, Mar 26, 2010 at 12:11:31PM +0100, Oleg Nesterov wrote: > > > Yes, this is broken. More precisely, this wasn't even supposed to work. > > > > > > Even stracing of the sub-init itself (or global init btw) has problems, > > > the straced init is not protected from unwanted signals. > > > > Is this impossible/very hard to do cleanly? I understand that container's > > init becomes vulnerable to signals sent from root-owned processes in the > > container. If so, the impact of this issue should be quite limited, no? > > Yes, probably we can ignore this. > > > > Yes. First of all, tracehook_report_clone_complete() reports the wrong pid nr, > > > as it seen inside the init's namespace. This is easy to fix, but I doubt this > > > can help. IIRC strace doesn't use PTRACE_GETEVENTMSG at all, it looks at eax > > > after syscall. > > > > > > which patch? > > > > The patch below posted by Matt. AIUI, it fixes the > > tracehook_report_clone_complete() part, which results in an observable > > change in strace's behaviour (not that it makes strace work, though). > > I guess it doesn't work because we need to fix strace, see "strace doesn't > use PTRACE_GETEVENTMSG" above. > > > Anyway, are there any remaining issues on the kernel side or does strace > > have to be taught about pid namespaces? > > At first glance, I don't see other problems, except sometimes the reported > pid is wrong (like in do_fork). > > > + ptrace_pid_vnr = nr; > > + if (unlikely(p->parent != p->real_parent)) { > > + rcu_read_lock(); > > + ptrace_pid_vnr = task_pid_nr_ns(p, p->parent->nsproxy->pid_ns); > > Yes, this is what I meant. > > But we should not do this in do_fork().
I'm puzzled. If not here, where should we do this? Or are you saying ptrace should take a reference to the pid, store it, and get the vnr during PTRACE_GETEVENTMSG? (drop the reference at detach or when a new pid reference comes in..)
> But once again. This change fixes the value in "tracee->ptrace_message == newpid", > but a quick grep shows that strace-4.5.19 doesn't use PTRACE_GETEVENTMSG at all.
You are correct. However strace and gdb aren't necessarily the only users of ptrace so wouldn't it still be good to fix this?
Cheers, -Matt Helsley
| |