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.
next prev parent 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.