RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v3]

[Larry Cable]

> the implementation I originally provided does not in fact solve the issue!
> 
> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`)  in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem).
> 
> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach
> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee.
> 
> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant).
> 
> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common.
> 
> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher".
> 
> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher".
> 
> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s).
> 
> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace.
> 
> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion.
> 
> therefore an "attacher" has two choices when attempting to attach:
> 
> - use the /proc/<pid>/root/tmp path to the "attachee's" /tmp (or its cwd)
>   - this works with both peers and descendants
> 
> - use /tmp
>   - this only works if the "attacher" and "attachee" share a /tmp in common
> 
> the obvious choice is to default to /proc/<pid>/root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc/<pid>/root (or cwd) path.
> 
> In these circumstances, the "attacher" can only resort to /tmp wh...

Larry Cable has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8342449: fixed missing param in throws msg and renamed local var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21688/files
  - new: https://git.openjdk.org/jdk/pull/21688/files/4bee5d1e..2e89bd53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21688/head:pull/21688

PR: https://git.openjdk.org/jdk/pull/21688