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.048 / U:0.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site