Bug 230850
| Summary: | /proc/PID/mem is not readable | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jan Kratochvil <jan.kratochvil> |
| Component: | elfutils | Assignee: | Roland McGrath <roland> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | cagney, drepper |
| Target Milestone: | --- | Keywords: | Patch, Reopened |
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-03-06 23:25:08 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 229424 | ||
| Attachments: | |||
|
Description
Jan Kratochvil
2007-03-03 18:25:43 UTC
Created attachment 149185 [details]
Kernel testcase for read(2)/mmap(2)/trace(2) `/proc/%d/mem' readers.
Testcase using read(2) or mmap(2) or ptrace(2) to read VDSO contents.
On local kernel-xen-2.6.19-1.2898.2.3.fc7.i686 only ptrace(2) works.
Probably to be submitted to RHTS later.
Created attachment 149186 [details]
elfutils-0.126 workaround using PTRACE_PEEKTEXT instead of `/proc/%d/mem'.
Here is a workaround for elfutils-0.126 that uses PTRACE_PEEKTEXT instead of
the original `/proc/%d/mem' pread64(2)ing code.
It somehow handles ptrace(2) recursivity for processes already being ptrace(2)d
from the current caller's process.
Created attachment 149248 [details]
test case
Run the attached test case with no args to duplicate -p PID behavior as seen
from eu-addr2line et al, and with argument "ptrace" to demonstrate how it works
when called from the thread that is ptrace'ing the target PID.
Try also e.g. "sh -c 'exec eu-addr2line -f -p $$ 0x40000420'". It is intended behavior in the upstream kernel and this is unchanged in Fedora kernels, that /proc/PID/mem reads are allowed only by that thread itself or by the thread that is ptrace'ing it. It was not always this way, but some "security" decision was made to disallow reads even by a thread that would be allowed to attach ptrace, if it is not actually doing ptrace at the time (so gdb can read). The libdwfl code that the -p option gets to, especially the vdso-grokking stuff, was not really intended necessarily to work standalone as it is entirely. It's more of an example of how things all plug together in the library support and what code you'd reuse in a more complex caller integrated with actual debugging stuff. In the fullness of time, there will be clean things to plug into instead of ptrace and /proc grovelling, and then -p PID support can use those and the vdso support will fall into place. Created attachment 149350 [details] Patch on-demand PTRACE_ATTACHING the inferior for /proc/PID/mem read(2). As there is needed some workaround of the current state proposing it for elfutils. Otherwise the same code should be present in all the applications using it. Your testcase from Comment 3 would be fine to also include for elfutils together with this patch (it would run without the "ptrace" argument and it should work). According to Roland this case never occurs as the only tool exhibiting it is `eu-addr2line -p ...'. Included a note in libunwind (Bug 229424): /* FIXME: Here we would fail for a process not being ourselves and not being PTRACE_ATTACHed for unwinding of VDSO symbols (such as sigreturn function from a signal handler on the 32-bit x86 platform). Fails read_proc_memory() with ESRCH on pread64() there. As this case probably never occurs with libunwind we do not workaround it. */ |