Bug 190128 - /proc/<pid>/smaps doesn't give any data
/proc/<pid>/smaps doesn't give any data
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
: Reopened
Depends On:
Blocks: 173278 208435 208589
  Show dependency treegraph
Reported: 2006-04-27 16:16 EDT by Kjartan Maraas
Modified: 2015-01-04 17:26 EST (History)
9 users (show)

See Also:
Fixed In Version: kernel-xen-2.6.18-1.2731.fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-09 19:47:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to linux-2.6-proc-self-maps-fix.patch (402 bytes, patch)
2006-05-10 20:19 EDT, Chris Ball
no flags Details | Diff
Fix gdb "gcore" command for kernel-2.6.17-1.2647.fc6.i686 (504 bytes, patch)
2006-09-17 21:14 EDT, Jan Kratochvil
no flags Details | Diff

  None (edit)
Description Kjartan Maraas 2006-04-27 16:16:51 EDT
Description of problem:
I can't get any data from the above with the current rawhide kernels. Any idea
what is causing it to be emtpy? 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Chris Ball 2006-05-09 13:43:23 EDT
Reproduced here on 2196.
Comment 2 Chris Ball 2006-05-09 16:06:02 EDT
This appears to be caused by linux-2.6-proc-self-maps-fix.patch, which
references #165351.  I don't have access to that bug.  The patch doesn't look
like it's intending to disable all of {,s}maps, so I'm inclined to suspect
something broke; I'd be happy to investigate further, but I'd want to hear more
about the aims of that patch (and why it isn't in mainline) first.
Comment 3 Chris Ball 2006-05-09 18:24:57 EDT
I tried applying jbj's patch in:


.. against 2196 to see if his patch for task->mm going NULL changed anything, 
but it doesn't.  I should add that /proc/self/{,s}maps works, it's the other
/proc/$pid/ entries that are returning empty.
Comment 4 Chris Ball 2006-05-09 23:55:24 EDT
I've started some basic debugging.  We're failing at __ptrace_may_attach(task),
called from base.c:mm_for_maps(), called from task_mmu.c:m_start().  The reason
/proc/self/maps is still working is that the conditional is:

    if (task->mm != current->mm && !__ptrace_may_attach(task))
        goto out;

So, we (rightly) never test __ptrace_may_attach() when current == task, but
whenever we do test it, it fails.  Tomorrow I hope to find out why; it may be
that may_attach (which __ptrace_may_attach is renamed from) changed incompatibly
on us.
Comment 5 Chris Ball 2006-05-10 20:19:58 EDT
Created attachment 128866 [details]
Patch to linux-2.6-proc-self-maps-fix.patch
Comment 6 Chris Ball 2006-05-10 20:23:24 EDT
Okay, I'm at a solution.  The polarity in the conditional above is incorrect --
__ptrace_may_attach() passes off to the registered LSMs, and they (cap_ptrace()
and selinux_ptrace()) return 0 on success, whereas the logic above goes to the
failure case unless it sees >0.

So, the exclamation mark above should go, and it looks like /proc/$pid/{,s}maps
have been broken since proc-self-maps.patch was applied.

I've just attached a patch to linux-2.6-proc-self-maps-fix.patch which removes
the !.  Tested on i386 with and without enforced selinux, and both
/proc/$pid/{,s}maps and /proc/self/{,s}maps now work.

Let me know if the diff-of-a-diff is discouraged; I wouldn't normally do such a
thing, but I don't see a better way to patch one of the shipped .diff files.
Comment 7 Dave Jones 2006-06-05 14:00:06 EDT
applied to cvs, will be in tomorrows rawhide.
Comment 8 Ernie Petrides 2006-08-29 18:39:53 EDT
Chris/Dave, I'm confused by the patch in comment #5.  I think the
original test was correct.  If __ptrace_may_attach() returns 0,
then access to /proc/<pid>/maps should be denied.

It used to be denied before the patch in bug 165351 comment #5
(only in RHEL4) due to the fact that read permissions were limited
to the /proc file owner.  After the patch, the permissions were
world-readable, so it became necessary to limit access to those
tasks that could do a PTRACE_ATTACH operation (besides itself).

If /proc/<pid>/smaps files contain data that really should be
world-readable, then I think the file open handling for the two
special files ("maps" versus "smaps") should be decoupled.

Do you both agree?
Comment 9 Kjartan Maraas 2006-08-29 19:05:16 EDT
Btw, this works just fine for me now. I get data as a normal user.
Comment 10 Kjartan Maraas 2006-08-29 19:39:40 EDT
Just a note to say that I get output for the processes I've got permission to
look at as a normal user, but get permission denied for processes running as
root as expected.
Comment 11 Jan Kratochvil 2006-09-17 21:14:01 EDT
Created attachment 136501 [details]
Fix gdb "gcore" command for kernel-2.6.17-1.2647.fc6.i686

This Bug corrupts gdb "gcore" nondestructive core files dumping used by
gdb dumps the core but it contains no mapped data sections as gdb opens
"/proc/PID/maps" being completely empty.
Attached patch is just the previous one rediffed/updated for the current
1. Unpack "gdb-*.src.rpm".
2. cd gdb/testsuite
3. runtest gdb.base/gcore.exp
On kernel-2.6.17-1.2647.fc6.i686 without the patch: 9 PASS, 6 FAIL
With the patch: 14 PASS, (0 FAIL)
Comment 12 Jan Kratochvil 2006-10-01 11:53:04 EDT
Comment on attachment 136501 [details]
Fix gdb "gcore" command for kernel-2.6.17-1.2647.fc6.i686

See Bug 208589 for the real patch.
This one hides the "maps" content for processes not ptrace(2)ing the target
Comment 13 Jan Kratochvil 2006-10-09 19:47:18 EDT
Bugfix found to be committed:
  revision 1.2731
  date: 2006/10/03 18:00:26;  author: davej;  state: Exp;  lines: +2 -1
  Fix breakage in /proc/*/smaps access control (#208589)
Verified in:

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