Bug 790456

Summary:	ptraced process behavior gone wacky in latest kernels
Product:	[Fedora] Fedora	Reporter:	Tom Horsley <horsley1953>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	16	CC:	gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, onestero
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-02-14 17:52:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Tom Horsley 2012-02-14 15:17:48 UTC

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.

Comment 1 Josh Boyer 2012-02-14 15:59:57 UTC

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.

Comment 2 Tom Horsley 2012-02-14 16:42:58 UTC

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.

Comment 3 Oleg Nesterov 2012-02-14 17:24:43 UTC

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

Comment 4 Tom Horsley 2012-02-14 17:52:06 UTC

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.