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
