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