8226919: attach in linux hangs due to permission denied accessing /proc/pid/root

[Sebastian Lövdahl]

Hi all,

I would be interesting in doing my first JDK contribution by 
contributing a fix for 8226919.
We stumbled upon this issue after having started migrating our 
Tomcat-based runtime environments
from Java 8 to Java 17.

A clear and simple reproducer is currently missing from 8226919. One way 
of reproducing it is by
- having a Java service that listens to a privileged port
- is run as a non-root user
- by a systemd service with AmbientCapabilities=CAP_NET_BIND_SERVICE.

This means that the process has elevated capabilities, and the Linux 
kernel seems to restrict
access to /proc/pid/root because of that. If e.g. jcmd <PID> is run as 
the same user as the service
is running as, the dynamic attach mechanism fails, because it cannot 
follow the /proc/pid/root
symlink and find the tmp folder of the target process where the 
.java_pidNNNN socket is created.
For the record, this worked fine with Java 8 before /proc/pid/root was 
used by the dynamic attach
mechanism.

The reason for using /proc/pid/root in the first place is sane and 
valid. It was done in 8179498 to
make attaching work across container boundaries. It seems like 8255008 
may revamp the attach
mechanism specifically for containers.

It looks like 
src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java 
already tries
to handle this specific case, but falls just short of doing it all the 
way. The createAttachFile
method checks if the target PID and the inner-most namespaced PID are 
equal or not. If they are
equal, we're in a non-container environment, and we are able to create 
/tmp/.attach_pidNNNN
directly without going through /proc/pid/root.

However, the same check is missing in the findSocketFile method; it 
blindly assumes that
/proc/pid/root will work and tries to open the socket via 
/proc/pid/root/tmp/.java_pidNNNN.

First of all, is there consensus that this should be fixed? If yes, are 
there any flaws in the
analysis above?

Best regards,
Sebastian Lövdahl