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

[Cyrill Gorcunov]

On Wed, Feb 15, 2012 at 04:38:16PM +0100, Oleg Nesterov wrote:
...
> >
> > Wait, how it's differ from other ptrace_may_access calls all over
> > the kernel? I suppose I'm missing something obvious?
> 
> For example? Say, mm_access() is fine because it returns ->mm
> which we are going to play with.

So, say we have

environ_read
  mm_for_maps
   mm_access
    success, and first reader continue here

then say task change own credentials and all
this sequence fails because access is not granted
anymore (say for second reader), but first reader
still able to continue reading because access was
graned earlier.

So I don't understand how it's different from what
is provided in this patch. What I'm missing?

> Once again, I am not saying that this code really has the security
> problems. I simply do not know. But it looks wrong without the
> comment. I do not really understand why do we need ptrace_may_access(),
> but whatever reason we have how we can trust it? Say, when KCMP_VM
> checks ->mm, all we know is that PTRACE_MODE_READ succeed in the
> past. This looks confusing, imho.

Adding the comment is not a problem. The problem is that I
dont understand if there error in patch or not, can we stick
with ptrace_may_access or need something different here?
The idea was exactly like -- if you have enough rights to
proceed ptrace_may_access then syscall should continue
executing and return comparision result.

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