Bug 196125
| Summary: | maps in proc pid directory can't be read by other process | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | IBM Bug Proxy <bugproxy> |
| Component: | kernel | Assignee: | Dave Jones <davej> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | pfrields, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | powerpc | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-07-26 03:25:32 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: | |||
This got fixed later. 2181 is nearly 300 revisions ago.. changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ACCEPTED |CLOSED
------- Additional Comments From shenlinf.com 2006-08-09 03:05 EDT -------
I downloaded kernel-2.6.17-1.2530.fc6 from
ftp://download.fedora.redhat.com/pub/fedora/linux/core/development/ppc64/os/Fedora/RPMS/,
applied and tested it. It worked fine.
The condition is a bit different with 2.6.16-1.2290 but it also makes the right
decision.
-------------
if (task->mm != current->mm && tracehook_allow_access_process_vm(task))
goto out;
task_unlock(task);
return mm;
-------------
Closing this defect. Thanks for debugging.
|
LTC Owner is: ssant.com LTC Originator is: shenlinf.com Problem description: I was testing May 1 FC5 on vestalp8. When I issued "cat /proc/self/maps", it showed the memory maps in its virtual address space successfully. But when I tried to show the maps file of other process, e.g. "cat /proc/1/maps", it showed nothing. strace showed that cat read zero byte from this file. ------------------ [root@vestalp8 ~]# cat /proc/1/maps [root@vestalp8 ~]# strace cat /proc/1/maps ... open("/proc/1/maps", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0 read(3, "", 1024) = 0 close(3) = 0 ... ------------------ If this is a customer issue, please indicate the impact to the customer: If this is not an installation problem, Describe any custom patches installed. Provide output from "uname -a", if possible: [root@vestalp8 fs]# uname -a Linux vestalp8.upt.austin.ibm.com 2.6.16-1.2181_FC6 #1 SMP Sun Apr 30 23:03:19 EDT 2006 ppc64 ppc64 ppc64 GNU/Linux Hardware Environment Machine type (p650, x235, SF2, etc.): 9119-595 Cpu type (Power4, Power5, IA-64, etc.): Power5 Describe any special hardware you think might be relevant to this problem: Please provide contact information if the submitter is not the primary contact. My backups are Shaowu Yang(shaowu.com) in Austin and Changhai Jiang(jiangchh.com) in China. Please provide access information for the machine if it is available. Is this reproducible? If so, how long does it (did it) take to reproduce it? Describe the steps: If not, describe how the bug was encountered: Is the system (not just the application) hung? If so, describe how you determined this: Did the system produce an OOPS message on the console? If so, copy it here: Is the system sitting in a debugger right now? If so, how long may it stay there? Additional information: This problem doesn't happen in RHEL4 U3 GA. Logged into the machine and could see the problem. Debugging ... I am not sure if this is a BUG per se. FC5 has these execshield patches which is responsible for this behaviour. When the maps file is created under /proc the permission given are E(PROC_TGID_MAPS, "maps", S_IFREG|S_IRUSR), While in case of vanilla kernels the above line looks like .. E(PROC_TGID_MAPS, "maps", S_IFREG|S_IRUGO), Notice the last entry passed has been changed to S_IRUSR and not S_IRUGO. Because of these execshield changes cat /proc/1/maps does not display anything. The problem still exists in May 26 version. I am changing the version to 'devel' to properly reflect that this recreates on rawhide.