Messages in this thread | | | Date | Wed, 15 Feb 2012 21:53:19 +0400 | From | Cyrill Gorcunov <> | Subject | Re: + 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
| |