Messages in this thread | | | Subject | Re: /proc/$PID/mem rationale | From | Valdis.Kletnieks@vt ... | Date | Wed, 04 May 2005 13:13:40 -0400 |
| |
On Wed, 04 May 2005 17:40:31 +0200, Serge van den Boom said:
> Could someone explain the reasoning behind these two design decisions > regarding /proc/$PID/mem? > - You can only read() from this file from a process which is attached to > the file's process through ptrace(). Why this requirement? > The following command line could be rather useful, but the ptrace() > requirement prevents this from working: > dd if=/proc/$SOME_PID/mem bs=1 seek=$ADDRESS
It's prohibited *because* it could be rather useful - to a hacker. It's an issue of information leakage - there are some corner cases where the permissions on /proc/PID/mem would appear to allow a read, but you don't in fact want to allow it (for the full list, look at the ptrace() code and the tests it makes for things like euid != uid and so on). There's a bunch of race conditions in there too.
> - You can only read() from the mem file from the process that open()ed it. > Even if the ptrace() requirement were dropped, you wouldn't be able > to do something like the following command because of this: > dd bs=1 seek=$ADDRESS < /proc/$SOME_PID/mem
Same reasons. ptrace() is able to make some checks and set some bits that read() isn't allowed anywhere near (in particular, ptrace() can *stop* a process so it can't race - read() can't do that.)
[unhandled content-type:application/pgp-signature] | |