All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cong Wang <xiyou.wangcong@gmail.com>
To: Cong Wang <xiyou.wangcong@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Vasiliy Kulikov <segoon@openwall.com>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH 5/6] proc: use task_access_lock() instead of ptrace_may_access()
Date: Thu, 12 Apr 2012 21:22:10 +0800	[thread overview]
Message-ID: <4F86D702.30209@gmail.com> (raw)
In-Reply-To: <1334123976-11681-5-git-send-email-xiyou.wangcong@gmail.com>

On 04/11/2012 01:59 PM, Cong Wang wrote:
> There are several places in fs/proc/base.c still use ptrace_may_access()
> directly to check the permission, actually this just gets a snapshot of
> the permission, nothing prevents the target task from raising the priviledges
> itself, it is better to use task_access_lock() for these places, to hold
> the priviledges.
>
Hi, Andrew,

Please drop this patch, it introduces a deadlock when execve() a 
/proc/<pid>/exec file, and it is not a big improvement nor fixes any 
bugs, so let's just drop this one.

Thanks!

  reply	other threads:[~2012-04-12 13:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-11  5:59 [PATCH 1/6 v3] proc: clean up /proc/<pid>/environ handling Cong Wang
2012-04-11  5:59 ` [PATCH 2/6] proc: unify ptrace_may_access locking code Cong Wang
2012-04-11  5:59 ` [PATCH 3/6] proc: remove mm_for_maps() Cong Wang
2012-04-12  0:38   ` Hugh Dickins
2012-04-11  5:59 ` [PATCH 4/6] proc: use mm_access() instead of ptrace_may_access() Cong Wang
2012-04-11  5:59 ` [PATCH 5/6] proc: use task_access_lock() " Cong Wang
2012-04-12 13:22   ` Cong Wang [this message]
2012-04-12 15:29     ` Djalal Harouni
2012-04-11  5:59 ` [PATCH 6/6] proc: use IS_ERR_OR_NULL() Cong Wang
2012-04-12  0:41   ` Hugh Dickins
2012-04-12 13:17     ` Cong Wang
2012-04-12 13:23   ` Alexey Dobriyan
2012-04-12 18:46     ` KOSAKI Motohiro
2012-04-12 19:26       ` Hugh Dickins
2012-04-12 19:31         ` Andrew Morton

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=4F86D702.30209@gmail.com \
    --to=xiyou.wangcong@gmail.com \
    --cc=adobriyan@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=rientjes@google.com \
    --cc=segoon@openwall.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.