lkml.org 
[lkml]   [2012]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: + syscalls-x86-add-__nr_kcmp-syscall-v8.patch added to -mm tree
On Wed, Feb 15, 2012 at 05:22:22PM +0100, Oleg Nesterov wrote:
>
> > So I don't understand how it's different from what
> > is provided in this patch. What I'm missing?
>
> environ_read() does
>
> mm = mm_access(task);
> if (mm)
> do_something(mm);
>
> even if it races with, say, execve(setuid_app) we can't read the
> new ->mm.

Wait, I'm confused

process 1 (reader) process 2 ("task" itself)
mm = mm_access(task);
task changes own credentials
so reader can't access on next
read if it would try, but since
access already granted... it
continues do_something(mm)
if (mm)
do_something(mm);

So in the patch I tried the same, once access is granted it
belongs to a caller.

>
> while your code (very roughly) does something like
>
> mm = mm_access(task);
> if (mm)
> do_something(task->mm);
>
> while it is quite possible that mm != task->mm.

Oleg, could you please explain me where it happens
that task->mm (I've got access to) will be changed
to some new -mm while I'm inspecting it.

If permission changed while the caller inside syscall,
it's the same situation as with mm_access above. No?

>
> My only point is: this check is obviously racy, and thus it looks
> confusing. Whether this is fine or not, I do not know. Personally
> I see no reason for ptrace_may_access(), but I am not security
> expert.

The idea was -- non-privilege caller should not have access
to privileged tasks.

Cyrill


\
 
 \ /
  Last update: 2012-02-15 18:55    [W:0.065 / U:1.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site