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.)
Attachment:
pgpfIsNsxaqTY.pgp
Description: PGP signature
- Follow-Ups:
- Re: /proc/$PID/mem rationale
- From: Serge van den Boom <[email protected]>
- Re: /proc/$PID/mem rationale
- References:
- /proc/$PID/mem rationale
- From: Serge van den Boom <[email protected]>
- /proc/$PID/mem rationale
- Prev by Date: [PATCH] device-mapper dm-emc: Fix a memset
- Next by Date: Re: [RFC][PATCH] update SubmittingPatches to clarify attachment policy
- Previous by thread: /proc/$PID/mem rationale
- Next by thread: Re: /proc/$PID/mem rationale
- Index(es):
 |