ADDITIONAL SYSTEM INFORMATION :
Debian Linux 64-bit 9.5
OpenJDK 11.0.4 (11.0.3 wasn't viable because of JDK-8222754)

A DESCRIPTION OF THE PROBLEM :
Beginning with JDK-8179498 attach was changed to locate the socket using a path relative to /proc/pid/root to support attach inside of a container. However, dereferencing this symlink is governed by ptrace access mode PTRACE_MODE_READ_FSCREDS which may not succeed when running as the user running the JRE. This breaks running jcmd and jmap as the same user the JVM is running as.

In our case /tmp/.java_pid##### is accessible as the user running the JVM so earlier versions of the command-line tools are able to see the JVM even on the same system:
user@host:~# /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/jcmd -l
9378 sun.tools.jcmd.JCmd -l
5837
user@host:~# /usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/jcmd -l
9408 jdk.jcmd/sun.tools.jcmd.JCmd -l

In both cases process 5837 is still running and is visible to the output of jps -l:
user@host:~$ /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/jps -l
10056 sun.tools.jps.Jps
5837
user@host:~$ /usr/lib/jvm/java-1.11.0-openjdk-amd64/bin/jps -l
5837
10079 jdk.jcmd/sun.tools.jps.Jps

and the Java 8 jcmd is able to send commands to the 5837 process:
user@host:~$ /usr/lib/jvm/java-1.8.0-openjdk-amd64/bin/jcmd 5837 VM.version
5837:
OpenJDK 64-Bit Server VM version 11.0.4+4-post-Debian-1
JDK 11.0.4

because /tmp/.java_pid##### is resolvable by user.

Attempting to invoke jmap or jcmd including the PID directly instead of searching for it first results in the following:
Exception in thread "main" com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /proc/5837/root/tmp/.java_pid5837: target process 5837 doesn't respond within 10500ms or HotSpot VM not loaded
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:100)
        at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
        at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
        at jdk.jcmd/sun.tools.jmap.JMap.executeCommandForPid(JMap.java:128)
        at jdk.jcmd/sun.tools.jmap.JMap.dump(JMap.java:196)
        at jdk.jcmd/sun.tools.jmap.JMap.main(JMap.java:114)

Additional details: this JRE is created using JNI from an application that forks and changes uid to run the child Java process as a different user with a small set of retained capabilities (using Apache commons-daemon) so the current workaround we're looking into is if changing that pattern is effective but until then this represents a serious regression for us.

REGRESSION : Last worked in version 8u212

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Launch Apache commons daemon 1.1.0 as root with argument `-user <user>` with a Java class that implements the Daemon interface and Java 10+ in JAVA_HOME
2) Run jps -v as <user> to locate PID
3) Run jcmd -l as <user> to see PID is missing
4) Run jmap -dump:live,format=b,file=/home/user/heap.hprof 5837 as <user> and see the AttachNotSupportedException

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
jcmd -l shows the expected PID; jmap generates a heap dump
ACTUAL -
jcmd -l is missing the PID
jmap exits after logging AttachNotSupportedException

---------- BEGIN SOURCE ----------
https://github.com/apache/commons-daemon/blob/master/src/samples/SimpleDaemon.java
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
None yet known

FREQUENCY : always