JDK-7050524 : SA, jinfo, jmap, jstack don't work on Ubuntu > 10.10: DebuggerException: Can't attach to the process
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: hs20,5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2011-06-01
  • Updated: 2015-07-28
  • Resolved: 2011-06-21
Related Reports
Relates :  
JDK-8059035 - Break the (implicit) dependency from jdk.jcmd to jdk.hotspot.agent
Relates :  
JDK-7160774 - jinfo, jmap, jstack man pages should document ptrace restrictions in recent Ubuntu versions
Relates :  
JDK-7112802 - jinfo fails to attach on MacOS X
Relates :  
JDK-7129704 - MAC: SA tools requires extra privileges (was: No AttachProvider implemented for Mac OS X)
Description
SA does not work on Ubuntu 11.04 or Ubuntu 10.10:

java.io.IOException
        at sun.jvm.hotspot.jdi.SAPIDAttachingConnector.attach(SAPIDAttachingConnector.java:126)
        at nsk.share.sajdi.Binder.attachToDebugee(Binder.java:133)
        at nsk.share.sajdi.Binder.bindToDebugee(Binder.java:45)
        at nsk.sajdi.VirtualMachine.canBeModified.canbemodif001.runIt(canbemodif001.java:51)
        at nsk.sajdi.VirtualMachine.canBeModified.canbemodif001.run(canbemodif001.java:26)
        at nsk.sajdi.VirtualMachine.canBeModified.canbemodif001.main(canbemodif001.java:21)
Caused by: java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at sun.jvm.hotspot.jdi.SAPIDAttachingConnector.createVirtualMachine(SAPIDAttachingConnector.java:87)
        at sun.jvm.hotspot.jdi.SAPIDAttachingConnector.attach(SAPIDAttachingConnector.java:111)
        ... 5 more
Caused by: sun.jvm.hotspot.debugger.DebuggerException: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.execute(LinuxDebuggerLocal.java:152)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach(LinuxDebuggerLocal.java:268)
        at sun.jvm.hotspot.HotSpotAgent.attachDebugger(HotSpotAgent.java:646)
        at sun.jvm.hotspot.HotSpotAgent.setupDebuggerLinux(HotSpotAgent.java:634)
        at sun.jvm.hotspot.HotSpotAgent.setupDebugger(HotSpotAgent.java:339)
        at sun.jvm.hotspot.HotSpotAgent.go(HotSpotAgent.java:314)
        at sun.jvm.hotspot.HotSpotAgent.attach(HotSpotAgent.java:158)
        at sun.jvm.hotspot.jdi.VirtualMachineImpl.createVirtualMachineForPID(VirtualMachineImpl.java:222)
        ... 11 more
Caused by: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.attach0(Native Method)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.access$100(LinuxDebuggerLocal.java:51)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$1AttachTask.doit(LinuxDebuggerLocal.java:259)
        at sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal$LinuxDebuggerLocalWorkerThread.run(LinuxDebuggerLocal.java:127)

Reproduces at least up to JDK 7 b80.


jmap fails with same error:
Attaching to process ID 6286, please wait...
Error attaching to process: sun.jvm.hotspot.debugger.DebuggerException: Can't attach to the process
In addition to the Serviceability Agent (SA), this issue also
affects the Java tools that depend on the SA:

    $JAVA_HOME/bin/jinfo
    $JAVA_HOME/bin/jmap
    $JAVA_HOME/bin/jstack -F
Comments
EVALUATION Sharon Z. has written a release note for this issue. See "Public Comments" note #1 and also see the "Work Around". Closing this bug as "will not fix" since there are no practical code changes that we can make in SA to deal with this new policy in Ubuntu 10.10.
21-06-2011
PUBLIC COMMENTS Here is Sharon's blurb for the release notes: Ubuntu 10.10 and newer has a new default security policy that affects Serviceability commands. This policy prevents a process from attaching to another process owned by the same UID if the target process is not a descendant of the attaching process. The new security policy affects the following components: * Serviceability Agent (SA) * jinfo * jmap * jstack -F You can revert to the more permissive policy in one of two ways: 1) temporarily (until the next reboot) by changing the value to 0 in /proc/sys/kernel/yama/ptrace_scope, or 2) more permanently by changing the value to 0 in /etc/sysctl.d/10-ptrace.conf and rebooting. Option 1 does not require a reboot and option 2 does require a reboot.
21-06-2011
WORK AROUND The following will change the kernel's yama/ptrace_scope variable temporarily, i.e., until the next reboot: $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope For a more permanent change: $ sudo your-favorite-editor /etc/sysctl.d/10-ptrace.conf <edit the following line> kernel.yama.ptrace_scope = 1 <to look like this> kernel.yama.ptrace_scope = 0 and reboot your system.
07-06-2011
EVALUATION I just changed /etc/sysctl.d/10-ptrace.conf 22c22,24 < kernel.yama.ptrace_scope = 1 --- > # kernel.yama.ptrace_scope = 1 > # Use PTRACE scope of "0" so Serviceability Agent (SA) can work: > kernel.yama.ptrace_scope = 0 rebooted jsn-vm931 and verified that the canbemodif001 now works.
06-06-2011
EVALUATION Here is a snippet from the following Ubuntu man page: http://manpages.ubuntu.com/manpages/natty/man2/ptrace.2.html PTRACE_ATTACH Attaches to the process specified in pid, making it a traced "child" of the calling process; the behavior of the child is as if it had done a PTRACE_TRACEME. The calling process actually becomes the parent of the child process for most purposes (e.g., it will receive notification of child events and appears in ps(1) output as the child's parent), but a getppid(2) by the child will still return the PID of the original parent. The child is sent a SIGSTOP, but will not necessarily have stopped by the completion of this call; use wait(2) to wait for the child to stop. (addr and data are ignored.) Since Ubuntu 10.10, PTRACE_ATTACH is not allowed against arbitrary matching-uid processes. The traced "child" must be a descendant of the tracer or must have called prctl(2) using PR_SET_PTRACER, with the pid of the tracer (or one of its ancestors). For more details, see /etc/sysctl.d/10-ptrace.conf. And here is the relevant config file from jsn-vm931: :::::::::::::: /etc/sysctl.d/10-ptrace.conf :::::::::::::: # The PTRACE system is used for debugging. With it, a single user process # can attach to any other dumpable process owned by the same user. In the # case of malicious software, it is possible to use PTRACE to access # credentials that exist in memory (re-using existing SSH connections, # extracting GPG agent information, etc). # # A PTRACE scope of "0" is the more permissive mode. A scope of "1" limits # PTRACE only to direct child processes (e.g. "gdb name-of-program" and # "strace -f name-of-program" work, but gdb's "attach" and "strace -fp $PID" # do not). The PTRACE scope is ignored when a user has CAP_SYS_PTRACE, so # "sudo strace -fp $PID" will work as before. For more details see: # https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace # # For applications launching crash handlers that need PTRACE, exceptions can # be registered by the debugee by declaring in the segfault handler # specifically which process will be using PTRACE on the debugee: # prctl(PR_SET_PTRACER, debugger_pid, 0, 0, 0); # # In general, PTRACE is not needed for the average running Ubuntu system. # To that end, the default is to set the PTRACE scope to "1". This value # may not be appropriate for developers or servers with only admin accounts. kernel.yama.ptrace_scope = 1 In Serviceability Agent (SA) use cases, having the target Java process use the PR_SET_PTRACER prtctl() is not practical. The target Java process has no way of knowing the PID of the SA process that is trying to attach to it.
06-06-2011