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

[Laurence Cable]

I should also note that on other *nix'es (where there is no /proc to 
introspect) the default behavior is simply to send the QUIT regardless.

In the case of Linux, this addition obviates the chance of an attach 
killing the target should it not be catching QUIT!


On 11/12/24 3:45 PM, Laurence Cable wrote:
>
>
>
> On 11/12/24 3:33 PM, Serguei Spitsyn wrote:
>> On Thu, 7 Nov 2024 04:48:28 GMT, Serguei Spitsyn 
>> <sspitsyn at openjdk.org> wrote:
>>
>>>> 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
>>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java 
>>> line 268:
>>>
>>>> 266:          * however we can also check the target pid's signal 
>>>> masks to see if it catches SIGQUIT and only do so if in
>>>> 267:          * fact it does ... this reduces the risk of killing 
>>>> an innocent process in the current ns as opposed to
>>>> 268:          * attaching to the actual target JVM ... c.f: 
>>>> checkCatchesAndSendQuitTo() below.
>>> This still looks pretty risky and dangerous. I'm thinking if it'd 
>>> make sense to check that the target process is a VM process. At 
>>> least, we know how VM processes can use the signal mask. Another 
>>> concern is that the target VM process might be not exactly the same 
>>> VM the client was expecting to attach. I don't know what can be done 
>>> to ensure this correctness.
>> It should be okay to file a bug/rfe on this.
>
> it is not feasible to introspect on the target process to determine if 
> it is a JVM or not, this is the best case not to send SIGQUIT to a 
> process that is neither catching nor blocking it, where the default is 
> to terminate it!
>>
>> -------------
>>
>> PR Review Comment: 
>> https://git.openjdk.org/jdk/pull/21688#discussion_r1838967163
>