linux-kernel - Re: [PATCH 03/10] ptrace: implement PTRACE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 27 May 2011 20:21:21 +0200
From:	Tejun Heo <tj@...nel.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Denys Vlasenko <vda.linux@...glemail.com>,
	jan.kratochvil@...hat.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
	indan@....nu, bdonlan@...il.com
Subject: Re: [PATCH 03/10] ptrace: implement PTRACE_SEIZE

Hello,

On Thu, May 26, 2011 at 05:01:50PM +0200, Oleg Nesterov wrote:
> On 05/26, Tejun Heo wrote:
> > > Or we can change do_wait() to detach a zombie leader. In this case it
> > > is not clear what should we do if the debugger is the real parent.
> > > Perhaps do_wait() should do the same: detach a leader (but not reap).
> > > When the last thread does, the real parent will be notified again.
> > > IOW, wait(tgid) can succeed twice.
> >
> > Just letting PTRACE_DETACH work for zombies sounds much simpler to me.
> 
> Probably, but please note we have to modify do_wait() anyway. Otherwise
> in general the tracer simply can not know the tracee has exited. IOW,
> waitpid(zombie_leader_pid, WEXITED) should succeed without reaping if
> delay_group_leader(), then the tracer can do PTRACE_DETACH. But this is
> not symmetrical with sub-thread zombies.

Yes, complicated.  The task/process duality conflicts.  wait(2)
already is different for group leader and succeeds twice for the
ptracer and the real parent (when they're different).

If we relocate ptrace group leader zombie wait, as suggested, such
that it waits for the task itself rather than the whole group, we
would be taking away a feature - ptracer waiting for the whole process
to exit and having access to group exit code, which might not mean
much, I have no idea.

I think group leader wait becoming asymmetrical with sub-thread
zombies is perfectly fine - it already is.  But would it be okay to
change ptrace wait(2) on group leader to wait for the task itself
rather than the whole group?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/