Hide Forgot
Description of problem: In original fedora 16 kernel 3.1.0-7.fc16.x86_64, I could read the /proc/pid/mem file of a debugged pid (in order to grab more than 8 bytes at a time from the PEEKDATA function). In some recent kernel, this behavior has gone wacko. It still works in the initial debugged process, but if I am following children with the SETOPTIONS ptrace functions, then when a child process forks then execs, I do not appear to be able to read that exec'ed process /proc mem file. These are just the initial symptoms I'm reporting. I'm trying to devise a test program to demonstrate exactly what has changed, but I thought I'd go ahead and report it in case someone happens to know exactly what is going on and can tell me :-). Version-Release number of selected component (if applicable): kernel-3.2.5-3.fc16.x86_64 (I'm pretty sure kernel-3.2.3-2.fc16.x86_64 acted the same way as well). How reproducible: Every time I run my debugger tests for following a fork/exec. Steps to Reproduce: 1.see above 2. 3. Actual results: Reading of debugged child that has forked and execed fails. Expected results: Should have same access on child that forked and execed as I have on the parent I'm already debugging. Additional info: I'll add a test program when I pin down the symptoms more exactly.
This is probably due to: commit e268337dfe26dfc7efd422a804dbb27977a3cccc Author: Linus Torvalds <torvalds> Date: Tue Jan 17 15:21:19 2012 -0800 proc: clean up and fix /proc/<pid>/mem handling Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very robust, and it also doesn't match the permission checking of any of the other related files. This changes it to do the permission checks at open time, and instead of tracking the process, it tracks the VM at the time of the open. That simplifies the code a lot, but does mean that if you hold the file descriptor open over an execve(), you'll continue to read from the _old_ VM. That is different from our previous behavior, but much simpler. If somebody actually finds a load where this matters, we'll need to revert this commit. I suspect that nobody will ever notice - because the process mapping addresses will also have changed as part of the execve. So you cannot actually usefully access the fd across a VM change simply because all the offsets for IO would have changed too. Reported-by: Jüri Aedla <asd> Cc: Al Viro <viro.org.uk> Signed-off-by: Linus Torvalds <torvalds> which went in as a security fix. You probably want to email upstream about your usecase and see what they say.
I'll look at the code. I would have thought I was already closing the fd on exec, but maybe I'm not. If I can fix all my problems by closing and reopening the fd across the exec, that shouldn't be difficult.
(In reply to comment #2) > > If I can fix all my problems by closing > and reopening the fd across the exec, that shouldn't be difficult. Yes, please. I do not think it is possible to return to the previous semantics of /proc/pid/mem. BTW, on the recent kernel you can use sys_process_vm_readv/writev instead, it doesn't need fd/open/etc.
Thanks for the info. I guess I'll need to investigate the new sys_process_vm stuff and add yet another thing for my ptrace-features program to detect and use if available. I did indeed find that all my problems disappeared when I closed the fd and reopened it (though the logic in Linus' comment is a little flawed since you can easily re-read the maps without ever closing the mem file, which is what the code was doing previously). Again, thanks to everyone for the rapid response with exactly the info I needed. I guess I can close this as not a bug.