RFR: 8327114: Attach in Linux may have wrong behaviour when pid == ns_pid (Kubernetes debug container)

Sebastian Lövdahl duke at openjdk.org
Mon May 6 16:17:51 UTC 2024


On Fri, 3 May 2024 17:40:54 GMT, jdoylei <duke at openjdk.org> wrote:

> > I think it boils down to the same reason as why the fix for JDK-8226919 was needed in the first place - a non-root user cannot read the symlinks in `/proc/<pid>/ns` for a process running with more privileges even though it's run by the same non-root user.
> 
> @slovdahl - In that test case (target JVM process has more privileges), where is the attach file created? Does jcmd end up writing it to `/tmp`? Or does `/proc/<pid>/cwd` work? Just curious whether the elevated-privileges scenario affects the attach file and socket file locations equally.

Yes, the attach file ends up in `/tmp`. Elevated privileges means that at least `/proc/<pid>/root`, `/proc/<pid>/cwd` and `/proc/<pid>/exe` are unreadable.


slovdahl at ubuntu2204:/proc/942992$ ls -lh cwd root 
ls: cannot read symbolic link 'cwd': Permission denied
ls: cannot read symbolic link 'root': Permission denied
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  6 19:06 cwd
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  6 19:06 root


> regardless I think the added check for mnt ns comparison "adds value" by
> expressing the constraints explicitly vs comparing pid & ns pid

Yep, agreed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2096419600


More information about the serviceability-dev mailing list