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

[FabF <fabian.frederick@skynet.be>]

On Mon, 2004-07-05 at 16:22, Tigran Aivazian wrote:
> 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?

FYI may_ptrace_attach plugged somewhere between 2.4.21 & 22.This one get
used as is (ie without MAY_PTRACE) in proc_pid_environ but dunno about
reason why CAP_SYS_PTRACE isn't authoritative elsewhere.

Regards,
FabF



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