Re: execve-under-ptrace API bug (was Re: Ptrace documentation, draft #3)

[Oleg Nesterov <oleg@redhat.com>]

On 05/30, Denys Vlasenko wrote:
>
> Consider how strace tracks its tracees. Currently, it remembers
> their pids - sometimes by remembering clone's return values!
> This is hopelessly broken wrt pid namespaces.

Yes. Unless the tracer lives in the same namespace it can't use
RAX as the pid. This return value is only makes sense inside the
tracee's namespace.

There is another problem, tracehook_report_clone_complete()
sets PTRACE_GETEVENTMSG == global_pid. IOW, this value can't
be used unless the tracer runs in the root namespace.

> So I looked at removing all pid tracking from strace,

I am not sure... but you certainly know better what strace
can/should do.

> The idea is that strace can simply create a new tracee's data
> structure when it sees a new, never before seen pid popping up
> from waitpid

This can probably work for strace. Note that this means strace
can't detach all tracees gracefully, it simply doesn't know them
all. But probably strace doesn't need this.

> This works (I have a patch against a somewhat older strace),
> but now in light of this "interesting" execve-under-ptrace
> behavior it appears to have a flaw: all threads except the
> execve'ing one disappear without any notification to strace,
> therefore strace doesn't know which tracee data ("struct tcb"
> in strace-speak) need to be dropped!

I think there is no choice currently, strace should remember tgid.

> I think the API needs fixing.

ptrace() should not be pid/thread based ;) But this is offtopic now.

Oleg.