This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 196125 - maps in proc pid directory can't be read by other process
maps in proc pid directory can't be read by other process
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
powerpc Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-06-21 05:45 EDT by IBM Bug Proxy
Modified: 2015-01-04 17:27 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-25 23:25:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)

  None (edit)
Description IBM Bug Proxy 2006-06-21 05:45:18 EDT
LTC Owner is:
LTC Originator is:

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 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( in Austin and Changhai
Jiang( 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
Comment 1 Dave Jones 2006-07-25 23:25:32 EDT
This got fixed later.
2181 is nearly 300 revisions ago..
Comment 2 IBM Bug Proxy 2006-08-09 03:00:36 EDT

           What    |Removed                     |Added
             Status|ACCEPTED                    |CLOSED

------- Additional Comments From  2006-08-09 03:05 EDT -------
I downloaded kernel-2.6.17-1.2530.fc6 from,
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
        if (task->mm != current->mm && tracehook_allow_access_process_vm(task))
                goto out;
        return mm;

Closing this defect. Thanks for debugging. 

Note You need to log in before you can comment on or make changes to this bug.