lkml.org 
[lkml]   [2010]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2010-03-26 13:49    [W:0.207 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site