linux-kernel - Re: [PATCH 1/1] ptrace: do_notify_parent_cldstop: fix the wrong ->nsproxy usage

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]

Message-Id: <20090527010612.0264FFC36B@magilla.sf.frob.com>
Date:	Tue, 26 May 2009 18:06:11 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] ptrace: do_notify_parent_cldstop: fix the wrong
	->nsproxy usage

> While this change is correct in any case (I hope), I wonder whether
> we need another one:
[...]
> If the sub-thread is not traced, but ->group_leader is, perhaps it makes
> more sense to notify the leader's tracer, not parent?

I don't think so.

> Not that I think this is really important. Just curious about what was
> the intent.

Here is how I would describe the intent (admittedly this logic is
retrospective, not necessarily articulated as such when the code was
written).  If the the triggering task is ptrace'd, this report is "for
ptrace purposes"--even if it's the CLD_STOPPED case.  Otherwise, what's
being reported is "the whole POSIX process is now stopped as per POSIX
definitions".  The latter properly goes to the parent of the process,
which is the group_leader->real_parent.

Thanks,
Roland
--
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/