Hide Forgot
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: 1. 2. 3. Actual results: Expected results: Additional info:
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