On Tue, Apr 06, 2010 at 08:13:13AM -0700, Eric W. Biederman wrote:
> Matt Helsley <matthltc@xxxxxxxxxx> writes:
>
> > On Mon, Apr 05, 2010 at 08:44:43PM -0700, Roland McGrath wrote:
<snip>
> >> None of this has much of anything to do with strace, of course. As I've
> >> said, I don't see anything other than the PTRACE_GETEVENTMSG value for
> >> PTRACE_EVENT_{CLONE,FORK,VFORK} reports that is wrong in the kernel. As
> >> Oleg said, strace doesn't use that at all. (This is not the place to
> >> discuss the details of strace further.)
> >
> > Also, looking at proposed changes (utrace and Eric Biederman's setns())
> > storing a pid nr rather than a reference to a task struct or struct pid
> > probably won't be correct.
>
> My setns work has demonstrated that even for entering a namespace we
> never ever need to change the struct pid of a task. setns has no other
> bearing on this problem then to say there is no foreseeable reason to
> change the rules.
>
> > In the case of Eric Biederman's setns(), if capable of changing pid namespace,
> > we could have:
> >
> > Traced Tracer
> > fork()
> > ... (an arbitrary amount of time passes)
> > setns()
> > ptrace(GETEVENTMSG)
>
> Forget that. The pid namespace was architected so that we can ptrace a process
> in another pid namespace.
>
> > At which point returning a static pid number held in the message field
> > produces the wrong pid.
>
> No. A processes always sees pids from the context of it's original pid
> namespace. All setns does is affect which pid namespace children will
> be native in.
OK, good. So we can resolve the tasks/struct pids within the tracehook
and be done with it. Thanks Eric!
Cheers,
-Matt Helsley
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
