On Tue, 12 Nov 2024 20:39:55 GMT, Larry Cable <d...@openjdk.org> wrote:
>> 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. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8342449: minor changes in response to previous review comments It looks okay to me. But I've posted one question/request. We may need to file an RFE on it. What mach5 tests were run to make sure the fix caused no regression? ------------- PR Review: https://git.openjdk.org/jdk/pull/21688#pullrequestreview-2431038648
