Bug 190128

Reproduced here on 2196.

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.

I tried applying jbj's patch in:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191094

.. 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.

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.

Created attachment 128866 [details]
Patch to linux-2.6-proc-self-maps-fix.patch

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.

applied to cvs, will be in tomorrows rawhide.

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?

Btw, this works just fine for me now. I get data as a normal user.

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.

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
customers.
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
kernel.
Testcase:
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 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
process.

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:
  kernel-xen-2.6.18-1.2747.fc6.i686