Re: question about /proc/<PID>/mem in 2.4

[Tigran Aivazian]

On Mon, 5 Jul 2004, FabF wrote:
> > I noticed that in 2.4.x kernels the fs/proc/base.c:mem_read() function has 
> > this permission check:
> > 
> >         if (!MAY_PTRACE(task) || !may_ptrace_attach(task))
> >                 return -ESRCH;
> > 
> > Are you sure it shouldn't be like this instead:
> > 
> >         if (!MAY_PTRACE(task) && !may_ptrace_attach(task))
> >                 return -ESRCH;
> > 
> > Because, normally MAY_PTRACE() is 0 (i.e. for any process worth looking at :)
> > so may_ptrace_attach() is never even called.
> > 
> MAY_PTRACE is 1 normally AFAICS.The check as it stands wants both to
> have non zero returns so is more restrictive than the one you're asking
> for.

MAY_PTRACE is defined as:

#define MAY_PTRACE(task) \
        (task == current || \
        (task->parent == current && \
        (task->ptrace & PT_PTRACED) && task->state == TASK_STOPPED))

so, if a process (current) is interested in another process (task) which
is not itself and not one of its children then MAY_PTRACE is 0. and the
test in mem_read() immediately returns ESRCH error without checking
may_ptrace_attach() at all. I questioned this behaviour as being too
restrictive and would like to know the reason for it.

Surely, the super user (i.e. CAP_SYS_PTRACE in this context) should be 
allowed to read any process' memory without having to do the 
PTRACE_ATTACH/PTRACE_PEEKUSER kind of thing which strace(8) is doing?

Kind regards
Tigran

-
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/