/proc/$PID/mem rationale

Hi,

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
- 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
  The usefulness of this may be limited, but I haven't been able to find
  any reason not to allow such actions.

I would appreciate it if you could CC me in replies.

Cheers,

Serge van den Boom


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

---

• Follow-Ups:
  • Re: /proc/$PID/mem rationale
    • From: [email protected]

• Prev by Date: Re: [RCF] [PATCH] unprivileged mount/umount
• Next by Date: Re: IDE problems in 2.6.12-rc1-bk1 onwards (was Re: 2.6.12-rc3-mm1)
• Previous by thread: Cannot read from /dev/kmem
• Next by thread: Re: /proc/$PID/mem rationale
• Index(es):
  • Date
  • Thread

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]