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

[Laurence Cable]

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 <duke at 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