All of lore.kernel.org
 help / color / mirror / Atom feed
From: Djalal Harouni <tixxdz@opendz.org>
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 16:29:27 +0100	[thread overview]
Message-ID: <20120412152927.GA18097@dztty> (raw)
In-Reply-To: <4F86D702.30209@gmail.com>

Hi Cong,

On Thu, Apr 12, 2012 at 09:22:10PM +0800, Cong Wang wrote:
> 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.
I was going to ask about this since it seems that abusing lock_trace()
or task_access_lock() can cause problems.

Please see commit 5e442a493fc59f which reverts commit aa6afca5bcaba8101f
that tries to protect /proc/PID/fd** files


IMHO A solution for some of the simple /proc/<pid>/* files is to use
mm_access() check just after gathering data and before returning it to
userspace.

So IMO the original code of proc_pid_wchan() was correct, since that data
is not copied to userspace directly, and we can avoid the mm_access() and
the task->signal->cred_guard_mutex lock since we do not race against them,
we have already grabbed the 'wchan', a simple ptrace_may_access() check will
do the job.

(I guess there is a window against another execve and ptrace_may_access()
but that returned data is not useful anymore, is it ?).


For others I don't know what would be the best solution.

Thanks.

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

-- 
tixxdz
http://opendz.org

  reply	other threads:[~2012-04-12 15:25 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
2012-04-12 15:29     ` Djalal Harouni [this message]
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=20120412152927.GA18097@dztty \
    --to=tixxdz@opendz.org \
    --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 \
    --cc=xiyou.wangcong@gmail.com \
    /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.