All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Paul Moore <paul@paul-moore.com>
Cc: Stephen Smalley <sds@tycho.nsa.gov>,
	James Morris <james.l.morris@oracle.com>,
	Eric Paris <eparis@parisplace.org>,
	Evan McNabb <emcnabb@redhat.com>,
	Jan Stancek <jstancek@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selinux: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock()
Date: Fri, 6 Dec 2013 15:47:35 +0100	[thread overview]
Message-ID: <20131206144735.GA2674@redhat.com> (raw)
In-Reply-To: <2222358.CI2sulrSvj@sifl>

On 12/05, Paul Moore wrote:
>
> On Thursday, December 05, 2013 05:59:53 PM Oleg Nesterov wrote:
> >
> > Note: perhaps we should simply kill ptrace_parent(), it buys
> > almost nothing and it is obviously racy. Or perhaps we should
> > change it to ensure it can't wrongly return the natural parent
> > if it races with ptrace_detach.
>
> Can you elaborate on "kill ptrace_parent()"?  If the process is being traced
> we do need to fetch the tracer's task_struct for use in the SELinux access
> check at this bottom of the diff below.  If you have something better in mind
> than ptrace_parent() it would be helpful to share that ...

Sorry for confusion.

I meant that the code like

	tracer = ptrace_parent(p);
	if (tracer)
		do_something(tracer);

doesn't look better than just

	if (p->ptrace)
		do_something(p->parent);

but this is subjective of course.

And perhaps I am wrong. Because otoh the usage of ->ptrace should be
avoided outside of the core kernel code.

Mostly it annoys me because it is racy, without tasklist_lock it can
return ->real_parent (which never traced its child) if it races with
attach or detach, and I do not see a simple fix.

Oleg.




  reply	other threads:[~2013-12-06 14:46 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-05 16:59 [PATCH] selinux: selinux_setprocattr()->ptrace_parent() needs rcu_read_lock() Oleg Nesterov
2013-12-05 21:53 ` Paul Moore
2013-12-06 14:47   ` Oleg Nesterov [this message]
2013-12-14 15:16     ` Paul Moore
2013-12-14 16:32       ` Oleg Nesterov
2013-12-14 16:33         ` [PATCH v2] " Oleg Nesterov
2013-12-16 21:12           ` Paul Moore
2013-12-16 21:12             ` Paul Moore
2013-12-16 21:11         ` [PATCH] " Paul Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131206144735.GA2674@redhat.com \
    --to=oleg@redhat.com \
    --cc=emcnabb@redhat.com \
    --cc=eparis@parisplace.org \
    --cc=james.l.morris@oracle.com \
    --cc=jstancek@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=sds@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.