Bug 285761
| Summary: | /proc/<pid>/maps not always accessible when receiving PTRACE_EVENT_EXIT | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Magnus Vesterlund <magnus_vesterlund> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | low | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | rawhide | CC: | jan.kratochvil, kernel-maint, roland | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2007-11-12 22:18:27 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: | 312031, 312041, 437958 | ||||||||
| Attachments: |
|
||||||||
|
Description
Magnus Vesterlund
2007-09-11 11:40:06 UTC
Created attachment 192401 [details]
Test case.
Verified on: kernel-2.6.23-0.195.rc7.git3.fc8.x86_64 (It was a verification it is still buggy there in Comment 2.) You must not be root to make the test fail on the Fedora kernel. (The test really works even for non-root on the upstream kernels.) This problem is not really related to ptrace. It's a Fedora difference that AFAICT is more or less intentional, but at any rate I am not the sole person to ask about it. The issue is that Fedora makes maps et al not world-readable. In all kernels, the core dump code (even with ulimit -c 0) clears the process's (mm's) "dumpable" flag. Once this flag is clear, the /proc/pid file access all acts with the files owned by root rather than by the euid. Since maps has mode 400 in Fedora (444 upstream), you can't read it when it belongs to root, so you can no longer open your own child's /proc files for reading. This is probably an unintended confluence of factors motivated by different things. The 400 vs 444 is an intended security change in Fedora. The permission meaning of dumpable=0 is intended for keeping secure things that changed uids or something like that--a privileged daemon that switches to your uid does not dump a core file owned by you. The core dump code clearing dumpable is probably part of some necessary synchronization plan or something. All added together, they have the effect of denying a permission noone ever intended to deny (/proc files of a task that is in the process of dying by a core signal)--but this can only be seen in non-racy conditions when you are either looking at a zombie (which has no such info as e.g. maps left to show anyway) or are looking at a PTRACE_EVENT_EXIT stop. linux-2.6-execshield.patch is what changes the fs/proc/base.c permissions to cause this. Created attachment 223861 [details]
enhanced test case
This version of the test case displays the uid/mode of the proc file, which
demonstrates what's going on in different kernels clearly.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=00ec99da43a7c2aed46c6595aa271b84bb1b1462 A variant of my fix went in upstream today. This should hit rawhide in the fullness of time. It would be trivial to backport to 2.6.23 if this is worth bothering with fixing early for Fedora [678]. Both cases: event-exit-proc-environ event-exit-proc-maps verified as fixed on Fedora 8: kernel-2.6.24.3-12.fc8.x86_64 (F8) kernel-2.6.25-0.101.rc4.git3.fc9.x86_64 (Rawhide) |