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
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
powerpc Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2006-07-25 23:25:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description IBM Bug Proxy 2006-06-21 05:45:18 EDT
LTC Owner is: ssant@in.ibm.com
LTC Originator is: shenlinf@cn.ibm.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@us.ibm.com) in Austin and Changhai
Jiang(jiangchh@cn.ibm.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.
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
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ACCEPTED                    |CLOSED




------- Additional Comments From shenlinf@cn.ibm.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. 

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