Bug 190128 - /proc/<pid>/smaps doesn't give any data
Summary: /proc/<pid>/smaps doesn't give any data
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Keywords: Reopened
Depends On:
Blocks: 173278 208435 208589
TreeView+ depends on / blocked
Reported: 2006-04-27 20:16 UTC by Kjartan Maraas
Modified: 2015-01-04 22:26 UTC (History)
9 users (show)

Clone Of:
Last Closed: 2006-10-09 23:47:18 UTC

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

Description Kjartan Maraas 2006-04-27 20:16:51 UTC
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 17:43:23 UTC
Reproduced here on 2196.

Comment 2 Chris Ball 2006-05-09 20:06:02 UTC
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 22:24:57 UTC
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-10 03:55:24 UTC
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-11 00:19:58 UTC
Created attachment 128866 [details]
Patch to linux-2.6-proc-self-maps-fix.patch

Comment 6 Chris Ball 2006-05-11 00:23:24 UTC
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 18:00:06 UTC
applied to cvs, will be in tomorrows rawhide.

Comment 8 Ernie Petrides 2006-08-29 22:39:53 UTC
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 23:05:16 UTC
Btw, this works just fine for me now. I get data as a normal user.

Comment 10 Kjartan Maraas 2006-08-29 23:39:40 UTC
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-18 01:14:01 UTC
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 15:53:04 UTC
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 23:47:18 UTC
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.