just a thought ... what if the code were to recurse "up" the process
tree if the target JVM had elevated privs (and its /proc/... was not
accessible), in order to find an
ancestor whose /proc was accessible, since the JVM itself does not
modify its pid or mnt namespaces (or capabilities) only an ancestor
process could elevate the JVM.
once an ancestor with a readable /proc/.../root/tmp was located, that
"proc" could be interrogated to determine if the target JVM was present
in its
namespace by validating that the target nspid was present in therein,
then the attach could use the /proc/<ancestor>/root/tmp as the
"attach"directory path instead
of falling back on "/tmp" which potentially is not in the same mnt ns as
the attacher?
of course the recursion would stop at "1" ...
thoughts?
- Larry
On 5/6/24 10:37 AM, Sebastian Lövdahl wrote:
On Mon, 6 May 2024 17:29:05 GMT, Sebastian Lövdahl <d...@openjdk.org> wrote:
8327114: Attach in Linux may have wrong behaviour when pid == ns_pid
(Kubernetes debug container)
Sebastian Lövdahl has updated the pull request incrementally with one
additional commit since the last revision:
Reworked attach logic
I pushed an updated attempt at this now with d3e26a0c444e06ba9757fd528d72d83f56cd098b. Local
testing and `make test TEST="jtreg:test/hotspot/jtreg/containers"` + `make test
TEST="jtreg:test/hotspot/jtreg/serviceability"` indicate that all the known use-cases
work.
Still eager to see what you come up with @larry-cable. `createAttachFile` could
still be improved for example. And I would also be interested in looking into
writing some test for the elevated privileges case.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2096564990
