Re: + syscalls-x86-add-__nr_kcmp-syscall-v8.patch added to -mm tree

[Cyrill Gorcunov <gorcunov@openvz.org>]

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