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

[Sebastian Lövdahl]

On Mon, 3 Jun 2024 23:07:00 GMT, Larry Cable  wrote:

>> Sebastian Lövdahl has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - Remove unused `SELF_PID_NS`
>>  - Rewrite in line with suggestion from Larry Cable
>
> it looks as though I can take an existing jcmd test in the container 
> tests and quite quickly implement an 'elevated' sidecar test...
> 
> I'll work on that today and tomorrow, lets aim to get the 'fix' and the 
> test in before Thu!!!
> 
> Rgds
> 
> - Larry
> 
> On 6/3/24 10:24 AM, Sebastian Lövdahl wrote:
>>
>> Hi Larry, no worries. :)
>>
>> I can try to look into writing some tests for the elevated use-cases. 
>> but it will be quite much treading of new ground for me, so it could 
>> take some time to get it done.
>>
>> What's your take, do we need the new tests in this PR, or could it be 
>> done in a follow-up?
>>
>> —
>> Reply to this email directly, view it on GitHub 
>> ,
>>  
>> or unsubscribe 
>> .
>> You are receiving this because you were mentioned.Message ID: 
>> ***@***.***>
>>
> 
> --2ZFegatR1DQpyr1B5InvHtns
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> 
> 
>   
>   
> it looks as though I can take an existing jcmd test in the container
> tests and quite quickly implement an 'elevated' sidecar test...
> 
> I'll work on that today and tomorrow, lets aim to get the 'fix' and
> the test in before Thu!!!
> 
> Rgds
> 
> - Larry
> 
> On 6/3/24 10:24 AM, Sebastian Lövdahl
>   wrote:
> 
> 
>   Hi Larry, no worries. :)
>   I can try to look into writing some tests for the
> elevated use-cases. but it will be quite much treading of new
> ground for me, so it could take some time to get it done.
>   What's your take, do we need the new tests in this
> PR, or could it be done in a follow-up?
>   —
> Reply to this email directly,  href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2145749773__;Iw!!A...

Thanks a lot @larry-cable, appreciated! The new test passes locally for me. I 
pushed the new test to the PR, feel free to take a look.

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2148970901

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

[Laurence Cable]

On 6/4/24 5:57 AM, Sebastian Lövdahl wrote:

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
additional commits since the last revision:

  - Remove unused `SELF_PID_NS`
  - Rewrite in line with suggestion from Larry Cable

This is awesome, Larry. You're my hero :) Thanks a lot in advance!


I modified the container 
test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java to also 
perform a "non root user" test of an elevated JVM from a sidecar.


- Larry



-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2147462603
diff --git a/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java 
b/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
index f38adcf8b47..35749a1da55 100644
--- a/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
+++ b/test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java
@@ -38,13 +38,19 @@
  * @build EventGeneratorLoop
  * @run driver TestJcmdWithSideCar
  */
+import java.io.BufferedReader;
+import java.io.IOException;
+import java.io.InputStreamReader;
 import java.nio.file.Paths;
 import java.util.Arrays;
 import java.util.ArrayList;
+import java.util.Collections;
 import java.util.EnumSet;
 import java.util.List;
+import java.util.Optional;
 import java.util.concurrent.TimeUnit;
 import java.util.function.Consumer;
+import java.util.regex.Pattern;
 import java.util.stream.Collectors;
 import jdk.test.lib.Container;
 import jdk.test.lib.Utils;
@@ -61,6 +67,31 @@ public class TestJcmdWithSideCar {
 private static final long TIME_TO_WAIT_FOR_MAIN_METHOD_START = 50 * 1000; 
// milliseconds
 private static final String MAIN_CONTAINER_NAME = "test-container-main";
 
+private static final String UID = "uid";
+private static final String GID = "gid";
+
+private static final Pattern ID_PATTERN = Pattern.compile("uid=(?<" + UID 
+ ">\\d+)\\([^\\)]+\\)\\s+gid=(?<" + GID + ">\\d+).*");
+
+private static final Optional USER = 
ProcessHandle.current().info().user().map(
+user -> {
+try (var br = new BufferedReader(new InputStreamReader(new 
ProcessBuilder("id", user).start().getInputStream( {
+for (final var line : 
br.lines().collect(Collectors.toUnmodifiableList())){
+final var m = ID_PATTERN.matcher(line);
+
+if (m.matches()) {
+return "--user=" +m.group(UID) + ":" + 
m.group(GID);
+}
+}
+} catch (IOException e) {
+   // do nothing...
+}
+
+return null;
+}
+);
+
+private static final String NET_BIND_SERVICE = 
"--cap-add=NET_BIND_SERVICE"; 
+
 public static void main(String[] args) throws Exception {
 if (!DockerTestUtils.canTestDocker()) {
 return;
@@ -69,26 +100,28 @@ public static void main(String[] args) throws Exception {
 DockerTestUtils.buildJdkContainerImage(IMAGE_NAME);
 
 try {
-// Start the loop process in the "main" container, then run test 
cases
-// using a sidecar container.
-MainContainer mainContainer = new MainContainer();
-mainContainer.start();
-
mainContainer.waitForMainMethodStart(TIME_TO_WAIT_FOR_MAIN_METHOD_START);
-
-for (AttachStrategy attachStrategy : 
EnumSet.allOf(AttachStrategy.class)) {
-long mainProcPid = testCase01(attachStrategy);
-
-// Excluding the test case below until JDK-8228850 is fixed
-// JDK-8228850: jhsdb jinfo fails with ClassCastException:
-// s.j.h.oops.TypeArray cannot be cast to s.j.h.oops.Instance
-// mainContainer.assertIsAlive();
-// testCase02(mainProcPid, attachStrategy);
-
-mainContainer.assertIsAlive();
-testCase03(mainProcPid, attachStrategy);
-}
-
-mainContainer.waitForAndCheck(TIME_TO_RUN_MAIN_PROCESS * 1000);
+for (final boolean elevated : USER.isPresent() ? new Boolean[] { 
false, true } : new Boolean[]{ false }) {
+// Start the loop process in the "main" container, then run 
test cases
+// using a sidecar container.
+MainContainer mainContainer = new MainContainer();
+mainContainer.start(elevated);
+
mainContainer.waitForMainMethodStart(TIME_TO_WAIT_FOR_MAIN_METHOD_START);
+
+for (AttachStrategy attachStrategy : 
EnumSet.allOf(AttachStrategy.class)) {
+long mainProcPid = testCase01(attachStrategy, elevated);
+
+// Excluding the test case below until JDK-8228850 is fixed
+

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

[Sebastian Lövdahl]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

This is awesome, Larry. You're my hero :) Thanks a lot in advance!

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2147462603

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

[Larry Cable]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

it looks as though I can take an existing jcmd test in the container 
tests and quite quickly implement an 'elevated' sidecar test...

I'll work on that today and tomorrow, lets aim to get the 'fix' and the 
test in before Thu!!!

Rgds

- Larry

On 6/3/24 10:24 AM, Sebastian Lövdahl wrote:
>
> Hi Larry, no worries. :)
>
> I can try to look into writing some tests for the elevated use-cases. 
> but it will be quite much treading of new ground for me, so it could 
> take some time to get it done.
>
> What's your take, do we need the new tests in this PR, or could it be 
> done in a follow-up?
>
> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> .
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--2ZFegatR1DQpyr1B5InvHtns
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
  
it looks as though I can take an existing jcmd test in the container
tests and quite quickly implement an 'elevated' sidecar test...

I'll work on that today and tomorrow, lets aim to get the 'fix' and
the test in before Thu!!!

Rgds

- Larry

On 6/3/24 10:24 AM, Sebastian Lövdahl
  wrote:


  Hi Larry, no worries. :)
  I can try to look into writing some tests for the
elevated use-cases. but it will be quite much treading of new
ground for me, so it could take some time to get it done.
  What's your take, do we need the new tests in this
PR, or could it be done in a follow-up?
  —
Reply to this email directly, https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2145749773__;Iw!!ACWV5N9M2RV99hQ!K0MEZ8qTAcfQbuAvzL9Owp185kbnkkocR0vuh5wia4Zlg3fFzKwJo5WgGVBMUSe_N5Hef4teGHbUKcyPg2ou5TXc0g$;
 moz-do-not-send="true">view it on GitHub, or https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SLY6ZRE5DP7RNIRR3ZFSREFAVCNFSM6ABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVG42DSNZXGM__;!!ACWV5N9M2RV99hQ!K0MEZ8qTAcfQbuAvzL9Owp185kbnkkocR0vuh5wia4Zlg3fFzKwJo5WgGVBMUSe_N5Hef4teGHbUKcyPg2pvqMZDog$;
 moz-do-not-send="true">unsubscribe.
You are receiving this because you were mentioned.Message ID:
  
openjdk/jdk/pull/19055/c2145749773@github.com


  


--2ZFegatR1DQpyr1B5InvHtns--

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2146272805

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

[Larry Cable]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

On 6/3/24 10:24 AM, Sebastian Lövdahl wrote:
>
> Hi Larry, no worries. :)
>
> I can try to look into writing some tests for the elevated use-cases. 
> but it will be quite much treading of new ground for me, so it could 
> take some time to get it done.
>

given that the patch passes all the 'serviceability' and 'container' 
test cases including the sidecar test - all that appears to be needed is 
an elevated test case ... looking into that to see if one of the 
existing container test cases can
be extended ...

> What's your take, do we need the new tests in this PR, or could it be 
> done in a follow-up?
>
> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> .
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--geZr7l60uuZilPFq9LUV0FJ6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
  


On 6/3/24 10:24 AM, Sebastian Lövdahl
  wrote:


  Hi Larry, no worries. :)
  I can try to look into writing some tests for the
elevated use-cases. but it will be quite much treading of new
ground for me, so it could take some time to get it done.


given that the patch passes all the 'serviceability' and 'container'
test cases including the sidecar test - all that appears to be
needed is an elevated test case ... looking into that to see if one
of the existing container test cases can
be extended ...


  What's your take, do we need the new tests in this
PR, or could it be done in a follow-up?
  —
Reply to this email directly, https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2145749773__;Iw!!ACWV5N9M2RV99hQ!K0MEZ8qTAcfQbuAvzL9Owp185kbnkkocR0vuh5wia4Zlg3fFzKwJo5WgGVBMUSe_N5Hef4teGHbUKcyPg2ou5TXc0g$;
 moz-do-not-send="true">view it on GitHub, or https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SLY6ZRE5DP7RNIRR3ZFSREFAVCNFSM6ABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVG42DSNZXGM__;!!ACWV5N9M2RV99hQ!K0MEZ8qTAcfQbuAvzL9Owp185kbnkkocR0vuh5wia4Zlg3fFzKwJo5WgGVBMUSe_N5Hef4teGHbUKcyPg2pvqMZDog$;
 moz-do-not-send="true">unsubscribe.
You are receiving this because you were mentioned.Message ID:
  
openjdk/jdk/pull/19055/c2145749773@github.com


  


--geZr7l60uuZilPFq9LUV0FJ6--

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2146133176

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

[Larry Cable]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

going to take a look at a couple of the "containers" tests to see if I 
can "quickly" clone them to provide a bootstrap for this patch...

- Larry

On 6/3/24 10:24 AM, Sebastian Lövdahl wrote:
>
> Hi Larry, no worries. :)
>
> I can try to look into writing some tests for the elevated use-cases. 
> but it will be quite much treading of new ground for me, so it could 
> take some time to get it done.
>
> What's your take, do we need the new tests in this PR, or could it be 
> done in a follow-up?
>
> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> .
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--XIGzXIQgYm0WtZy9a5FZZTYy
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
  
going to take a look at a couple of the containers tests to see 
if
I can quickly clone them to provide a bootstrap for this 
patch...

- Larry

On 6/3/24 10:24 AM, Sebastian Lövdahl
  wrote:


  Hi Larry, no worries. :)
  I can try to look into writing some tests for the
elevated use-cases. but it will be quite much treading of new
ground for me, so it could take some time to get it done.
  What's your take, do we need the new tests in this
PR, or could it be done in a follow-up?
  —
Reply to this email directly, https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2145749773__;Iw!!ACWV5N9M2RV99hQ!K0MEZ8qTAcfQbuAvzL9Owp185kbnkkocR0vuh5wia4Zlg3fFzKwJo5WgGVBMUSe_N5Hef4teGHbUKcyPg2ou5TXc0g$;
 moz-do-not-send="true">view it on GitHub, or https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67SLY6ZRE5DP7RNIRR3ZFSREFAVCNFSM6ABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVG42DSNZXGM__;!!ACWV5N9M2RV99hQ!K0MEZ8qTAcfQbuAvzL9Owp185kbnkkocR0vuh5wia4Zlg3fFzKwJo5WgGVBMUSe_N5Hef4teGHbUKcyPg2pvqMZDog$;
 moz-do-not-send="true">unsubscribe.
You are receiving this because you were mentioned.Message ID:
  
openjdk/jdk/pull/19055/c2145749773@github.com


  


--XIGzXIQgYm0WtZy9a5FZZTYy--

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2146095382

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

[Sebastian Lövdahl]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

Hi Larry, no worries. :) 

I can try to look into writing some tests for the elevated use-cases. but it 
will be quite much treading of new ground for me, so it could take some time to 
get it done.

What's your take, do we need the new tests in this PR, or could it be done in a 
follow-up?

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2145749773

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

[Larry Cable]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

Hi Sebastian, sadly no I haven't. :(

it would be good to get it in, it would be good if @kevinjwalls could 
take a look.

as with regressions, I think as long as it passes the current set of 
tests then there are unlikely to be any regressions.

we really need a test to validate:

1) attach to elevated JVM

2) attach across container boundary
     a) to elevated JVM

- Larry

On 6/2/24 9:02 AM, Sebastian Lövdahl wrote:
>
> @larry-cable 
> 
>  
> gentle ping, did you get a chance to test it any further?
>
> Maybe @jerboaa 
> 
>  
> and/or @kevinjwalls 
> 
>  
> that reviewed #17628 
> 
>  
> / JDK-8226919  would like 
> to take a look at this fix as well?
>
> Maybe it's getting a bit late now, but it would be really awesome if 
> we could get this to land before RDP 1 (on Thursday the 6th), so we 
> avoid regressing any use-cases in the upcoming JDK 23.
>
> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> .
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--JJW8ycnoTBYUYFaUv43Mvg08
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
  
Hi Sebastian, sadly no I haven't. :(

it would be good to get it in, it would be good if @kevinjwalls
could take a look.

as with regressions, I think as long as it passes the current set of
tests then there are unlikely to be any regressions.

we really need a test to validate:

1) attach to elevated JVM

2) attach across container boundary
 a) to elevated JVM

- Larry

On 6/2/24 9:02 AM, Sebastian Lövdahl
  wrote:


  
  https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!LoZom5Qy8VCk9HqSqZZs1Puzt4Xaxwg1m1jhO_nw42rjeedWQiRNnG8KtRl1zulrnLYqYuV0TsTTXexnzUMt6ya6Ww$;
 ***@***.*** gentle ping, did you
get a chance to test it any further?
  Maybe https://urldefense.com/v3/__https://github.com/jerboaa__;!!ACWV5N9M2RV99hQ!LoZom5Qy8VCk9HqSqZZs1Puzt4Xaxwg1m1jhO_nw42rjeedWQiRNnG8KtRl1zulrnLYqYuV0TsTTXexnzUNoOyPEJg$;
 ***@***.*** and/or https://urldefense.com/v3/__https://github.com/kevinjwalls__;!!ACWV5N9M2RV99hQ!LoZom5Qy8VCk9HqSqZZs1Puzt4Xaxwg1m1jhO_nw42rjeedWQiRNnG8KtRl1zulrnLYqYuV0TsTTXexnzUNeZyFX-w$;
 ***@***.*** that reviewed https://github.com/openjdk/jdk/issues/17628; 
 data-hovercard-type="pull_request" 
data-hovercard-url="/openjdk/jdk/pull/17628/hovercard" 
href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/17628__;!!ACWV5N9M2RV99hQ!LoZom5Qy8VCk9HqSqZZs1Puzt4Xaxwg1m1jhO_nw42rjeedWQiRNnG8KtRl1zulrnLYqYuV0TsTTXexnzUP26kWhGg$;
 moz-do-not-send="true">#17628 / https://bugs.openjdk.org/browse/JDK-8226919; rel="nofollow" 
moz-do-not-send="true">JDK-8226919 would
like to take a look at this fix as well?
  Maybe it's getting a bit late now, but it would be
really awesome if we could get this to land before RDP 1 (on
Thursday the 6th), so we avoid regressing any use-cases in the
upcoming JDK 23.
  —
Reply to this email directly, https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2143912533__;Iw!!ACWV5N9M2RV99hQ!LoZom5Qy8VCk9HqSqZZs1Puzt4Xaxwg1m1jhO_nw42rjeedWQiRNnG8KtRl1zulrnLYqYuV0TsTTXexnzUPnr406TQ$;
 moz-do-not-send="true">view it on GitHub, or 

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

[Sebastian Lövdahl]

On Wed, 22 May 2024 19:04:22 GMT, Larry Cable  wrote:

>> Sebastian Lövdahl has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - Remove unused `SELF_PID_NS`
>>  - Rewrite in line with suggestion from Larry Cable
>
> On 5/22/24 11:58 AM, Sebastian Lövdahl wrote:
>>
>> I haven't but I will BTW which linux capabilities should be
>> enabled in order to prevent a /proc/... style attach due to lack
>> of permissions to access target's /proc fs? Rgds - Larry
>>
>> I know for sure that |CAP_NET_BIND_SERVICE| prevents access to 
>> |/proc//root| at least. I don't know if there's any distinction 
>> between the different privileges a process can have to be honest, but 
>> I somehow got the impression that having /any/ privilege restricts 
>> access to |/proc//root| (among others). But right now I cannot 
>> recall what gave me that impression. There's a long list of 
>> capabilities though: 
>> https://man7.org/linux/man-pages/man7/capabilities.7.html 
>> 
>>
>> it lives ...it lives!!!
>>
>> I love it when a patch comes together!
>>
>> :)
>>
>> thx for testing this before my 1dt cup of coffee!
>>
>> Great feeling indeed! Ah, the best cup of the day, have a good one :)
>>
> 
> likewise Slainte Mhath!
> 
> - Larry
> 
>> —
>> Reply to this email directly, view it on GitHub 
>> ,
>>  
>> or unsubscribe 
>> .
>> You are receiving this because you were mentioned.Message ID: 
>> ***@***.***>
>>
> 
> --Rdb42IWaMAGxS5O004yPY6ws
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> 
> 
>   
>   
> 
> 
> On 5/22/24 11:58 AM, Sebastian Lövdahl
>   wrote:
> 
> 
>   
>   
> I haven't but I will BTW which linux capabilities
>   should be enabled in order to prevent a /proc/... style attach
>   due to lack of permissions to access target's /pro...

@larry-cable gentle ping, did you get a chance to test it any further?

Maybe @jerboaa and/or @kevinjwalls that reviewed #17628 / 
[JDK-8226919](https://bugs.openjdk.org/browse/JDK-8226919) would like to take a 
look at this fix as well?

Maybe it's getting a bit late now, but it would be really awesome if we could 
get this to land before RDP 1 (on Thursday the 6th), so we avoid regressing any 
use-cases in the upcoming JDK 23.

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2143912533

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

[Larry Cable]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

On 5/22/24 11:58 AM, Sebastian Lövdahl wrote:
>
> I haven't but I will BTW which linux capabilities should be
> enabled in order to prevent a /proc/... style attach due to lack
> of permissions to access target's /proc fs? Rgds - Larry
>
> I know for sure that |CAP_NET_BIND_SERVICE| prevents access to 
> |/proc//root| at least. I don't know if there's any distinction 
> between the different privileges a process can have to be honest, but 
> I somehow got the impression that having /any/ privilege restricts 
> access to |/proc//root| (among others). But right now I cannot 
> recall what gave me that impression. There's a long list of 
> capabilities though: 
> https://man7.org/linux/man-pages/man7/capabilities.7.html 
> 
>
> it lives ...it lives!!!
>
> I love it when a patch comes together!
>
> :)
>
> thx for testing this before my 1dt cup of coffee!
>
> Great feeling indeed! Ah, the best cup of the day, have a good one :)
>

likewise Slainte Mhath!

- Larry

> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> .
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--Rdb42IWaMAGxS5O004yPY6ws
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
  


On 5/22/24 11:58 AM, Sebastian Lövdahl
  wrote:


  
  
I haven't but I will BTW which linux capabilities
  should be enabled in order to prevent a /proc/... style attach
  due to lack of permissions to access target's /proc fs? Rgds -
  Larry
  
  I know for sure that CAP_NET_BIND_SERVICE
prevents access to /proc/pid/root
at least. I don't know if there's any distinction between the
different privileges a process can have to be honest, but I
somehow got the impression that having any privilege
restricts access to /proc/pid/root
(among others). But right now I cannot recall what gave me that
impression. There's a long list of capabilities though: https://urldefense.com/v3/__https://man7.org/linux/man-pages/man7/capabilities.7.html__;!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0JV3zd5SA$;
 rel="nofollow" 
moz-do-not-send="true">https://man7.org/linux/man-pages/man7/capabilities.7.html
  
it lives ...it lives!!!
I love it when a patch comes together!
:)
thx for testing this before my 1dt cup of coffee!
  
  Great feeling indeed! Ah, the best cup of the day,
have a good one :)


likewise Slainte Mhath!

- Larry


  —
Reply to this email directly, https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2125541556__;Iw!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0JG0EA7Zg$;
 moz-do-not-send="true">view it on GitHub, or https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67VJZL3MIT2HANZ3BLDZDTTG7AVCNFSM6ABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRVGU2DCNJVGY__;!!ACWV5N9M2RV99hQ!OuFFfoYFVnGvARkAQ11WdUPoVHR3GXEc-XbeZfOWFHFrQAJxR6-suOx9_j-qekgTrr5V66CAb7K0i0zi_0IYrO2-pA$;
 moz-do-not-send="true">unsubscribe.
You are receiving this because you were mentioned.https://github.com/notifications/beacon/ANTA67VXC2SXHYIOCXNVH3DZDTTG7A5CNFSM6ABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6WEYLI.gif;
 alt="" moz-do-not-send="true" width="1" height="1">Message
  ID: 
openjdk/jdk/pull/19055/c2125541556@github.com
  [
{
***@***.***": "http://schema.org";,
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "

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

[Sebastian Lövdahl]

On Wed, 22 May 2024 18:40:00 GMT, Larry Cable  wrote:

> I haven't but I will BTW which linux capabilities should be enabled in order 
> to prevent a /proc/... style attach due to lack of permissions to access 
> target's /proc fs? Rgds - Larry

I know for sure that `CAP_NET_BIND_SERVICE` prevents access to 
`/proc//root` at least. I don't know if there's any distinction between 
the different privileges a process can have to be honest, but I somehow got the 
impression that having _any_ privilege restricts access to `/proc//root` 
(among others). But right now I cannot recall what gave me that impression. 
There's a long list of capabilities though: 
https://man7.org/linux/man-pages/man7/capabilities.7.html

> it lives ...it lives!!!
>
> I love it when a patch comes together!
> 
> :)
> 
> thx for testing this before my 1dt cup of coffee!

Great feeling indeed! Ah, the best cup of the day, have a good one :)

-

PR Comment: https://git.openjdk.org/jdk/pull/19055#issuecomment-2125541556

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

[Larry Cable]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

I haven't but I will BTW which linux capabilities should be enabled in 
order to prevent a /proc/... style attach due to lack of permissions to 
access target's /proc fs?

Rgds

- Larry

On 5/22/24 2:37 AM, Sebastian Lövdahl wrote:
>
> Thanks for the explanation @larry-cable 
> ,
>  
> that makes sense. By chance, did you already test the Docker |--user| 
> case with the suggested patch? I don't have access to an environment 
> with rootless Docker at hand, but I may be able to set it up in a VM 
> if you didn't already test it.
>
> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> .
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--p6E1JhKjfAr6K0U0BUrS5J3x
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
  
I haven't but I will BTW which linux capabilities should be enabled
in order to prevent a /proc/... style attach due to lack of
permissions to access target's /proc fs?

Rgds

- Larry

On 5/22/24 2:37 AM, Sebastian Lövdahl
  wrote:


  
  Thanks for the explanation https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufP1OzXcw$;
 ***@***.***, that makes sense. By
chance, did you already test the Docker --user case with the suggested
patch? I don't have access to an environment with rootless
Docker at hand, but I may be able to set it up in a VM if you
didn't already test it.
  —
Reply to this email directly, https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2124324590__;Iw!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufIAfBLoA$;
 moz-do-not-send="true">view it on GitHub, or https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67WR5PKR6GOLQ5YR4YTZDRRNVAVCNFSM6ABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUGMZDINJZGA__;!!ACWV5N9M2RV99hQ!Itj8vWkvTqaQTLecUEfu_JZ6ABpWcUnNdgvMjd3DIa_lT3gj_sPLvswAzzOOr-hQRtP8oH0WAHwlplxItufsOv7sDg$;
 moz-do-not-send="true">unsubscribe.
You are receiving this because you were mentioned.https://github.com/notifications/beacon/ANTA67SYZIQHARL7TOTRLHLZDRRNVA5CNFSM6ABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT6T2PO4.gif;
 alt="" moz-do-not-send="true" width="1" height="1">Message
  ID: 
openjdk/jdk/pull/19055/c2124324590@github.com
  [
{
***@***.***": "http://schema.org";,
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2124324590";,
"url": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2124324590";,
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com";
}
}
]


  


--p6E1JhKjfAr6K0U0BUrS5J3x--

it lives ...it lives!!!

I love it when a patch comes together!

:)

thx for testing this before my 1dt cup of coffee!

Rgds

- Larry

On 5/22/24 4:21 AM, Sebastian Lövdahl wrote:
>
> I set up rootless Docker in a VM by following 
> https://docs.docker.com/engine/security/rootless 
> .
>
> ***@***.***:~$ systemctl status 

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

[Sebastian Lövdahl]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

I set up rootless Docker in a VM by following 
https://docs.docker.com/engine/security/rootless.


slovdahl@slovdahl-virtual-machine:~$ systemctl status --user docker.service 
● docker.service - Docker Application Container Engine (Rootless)
 Loaded: loaded (/home/slovdahl/.config/systemd/user/docker.service; 
enabled; vendor preset: enabled)
 Active: active (running) since Wed 2024-05-22 13:55:06 EEST; 5min ago
   Docs: https://docs.docker.com/go/rootless/
   Main PID: 3314 (rootlesskit)
  Tasks: 58
 Memory: 596.4M
CPU: 16.821s
 CGroup: 
/user.slice/user-1000.slice/user@1000.service/app.slice/docker.service
 ├─3314 rootlesskit --state-dir=/run/user/1000/dockerd-rootless 
--net=slirp4netns --mtu=65520 --slirp4netns-sandbox=auto 
--slirp4netns-seccomp=auto --disable-host-loopback --port-driver=builtin 
--copy-up=/etc --copy-up=/run --propagation=rslave /usr/bin/dockerd>
 ├─3325 /proc/self/exe --state-dir=/run/user/1000/dockerd-rootless 
--net=slirp4netns --mtu=65520 --slirp4netns-sandbox=auto 
--slirp4netns-seccomp=auto --disable-host-loopback --port-driver=builtin 
--copy-up=/etc --copy-up=/run --propagation=rslave /usr/bin/dock>
 ├─3343 slirp4netns --mtu 65520 -r 3 --disable-host-loopback 
--enable-sandbox --enable-seccomp 3325 tap0
 ├─3350 dockerd
 ├─3373 containerd --config 
/run/user/1000/docker/containerd/containerd.toml
 └─4116 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 
3a84c6c9f7b8ee6220b8953b65ff56639dd51335999cb37580292f4944ee0e65 -address 
/run/user/1000/docker/containerd/containerd.sock


Started a container running as my user:

slovdahl@slovdahl-virtual-machine:~$ docker run --name reproducer --rm -v 
.:/app -w /app eclipse-temurin:17 java Reproducer.java
Hello, World!
Bound to port 81


Using the Ubuntu OpenJDK 17 package:

slovdahl@slovdahl-virtual-machine:~$ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)

slovdahl@slovdahl-virtual-machine:~$ jcmd
4139 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
5965 jdk.jcmd/sun.tools.jcmd.JCmd

slovdahl@slovdahl-virtual-machine:~$ jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using mainline JDK without the changes in this PR:

slovdahl@slovdahl-virtual-machine:~$ /jdk/bin/jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using JDK built from this PR:

slovdahl@slovdahl-virtual-machine:~$ /jdk/bin/jcmd 4139 VM.version
4139:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using a sidecar container mounted into the same PID namespace with Eclipse 
Temurin 17:

slovdahl@slovdahl-virtual-machine:~$ docker run --interactive --tty --rm 
--pid=container:reproducer eclipse-temurin:17.0.11_9-jdk-jammy /bin/bash
root@b746aeae40d2:/# jcmd
44 jdk.jcmd/sun.tools.jcmd.JCmd
root@b746aeae40d2:/# jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11


Using a sidecar container mounted into the same PID namespace with mainline JDK 
(expected to fail):

slovdahl@slovdahl-virtual-machine:~$ docker run --interactive --tty --rm 
--pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
root@7b0c9dc87175:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
234 jdk.jcmd/sun.tools.jcmd.JCmd
root@7b0c9dc87175:/# /jdk/bin/jcmd 1 VM.version
1:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file 
/tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM 
not loaded
at 
jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:99)
at 
jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:58)
at 
jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:207)
at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113)
at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97)


Using a sidecar container mounted into the same PID namespace with JDK built 
from this PR:

slovdahl@slovdahl-virtual-machine:~$ docker run --interactive --tty --rm 
--pid=container:reproducer --volume /jdk/:/jdk ubuntu:22.04 /bin/bash
root@1ed0633e74eb:/# /jdk/bin/jcmd
1 jdk.compiler/com.sun.tools.javac.launcher.Main Reproducer.java
154 jdk.jcmd/sun.tools.jcmd.JCmd
root@1ed0633e74eb:/# /jdk/bin/jcmd 1 VM.version
1:
OpenJDK 64-Bit Server VM version 17.0.11+9
JDK 17.0.11

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

[Sebastian Lövdahl]

On Tue, 21 May 2024 21:06:22 GMT, Larry Cable  wrote:

>> Sebastian Lövdahl has updated the pull request incrementally with two 
>> additional commits since the last revision:
>> 
>>  - Remove unused `SELF_PID_NS`
>>  - Rewrite in line with suggestion from Larry Cable
>
> Hi Sebastian!
> 
> On 5/21/24 9:50 AM, Sebastian Lövdahl wrote:
>>
>> In these cases, is it not a requirement that jcmd is run as root?
>> So even if the target process is run with elevated privileges,
>> attaching would always work.
>>
> 
> the constraint (as I understand it) is based upon the filesystem access 
> to /proc//root/tmp, where the createAttachFile fails... if the 
> "attacher" (jcmd) has access, if it has the
> appropriate +og r/w access then it will be successful.
> 
> the "root" requirement comes from the default behavior of the container 
> mgmt (docker) running containers as 'root'.
> 
> if you employ the --user option to 'force' the container to adopt a 
> non-root identity jcmd will succeed if issued from the same 
> user because it has r/w access to the /proc//root/tmp
> 
> note: if the container is in a distinct uid ns (from the attacher) I 
> think the current checks performed by 
> *os::Posix::matches_effective_uid_and_gid_or_root* will complete since 
> the comparison is based on the uid values returned by the O.S 
> (independent of the fact that the uid's may exist in distinct uid ns'es!)
> 
>> Or is there some way to attach from host to container with a
>> non-root user that I'm missing?
>>
>> Or could it work in case the container is also run as a non-|root| user?
>>
> 
> the use case I was addressing with my proposal is when the jcmd 
> "container" (as a sidecar) is in the same pid ns as the target container 
> but in a different mnt ns (I believe this is the regression use case) in 
> that case falling back
> to /tmp will not work and since the attacher and the attachee do not 
> share a fs...
> 
> if the target JVM has elevated privs a (sidecar) attacher cannot use the 
> target's /proc//root/... hence my experiment to recurse "up" 
> the attachee's pid ns to look for a an un-privileged ancestor, which does
> share the same mnt ns as the attachee, so the attacher can use the 
> /proc//root/tmp to attach to the target... all things being 
> equal...
> 
> Rgds
> 
> - Larry
> 
>> —
>> Reply to this email directly, view it on GitHub 
>> ,
>>  
>> or unsubscribe 
>> 

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

[Larry Cable]

On Tue, 21 May 2024 17:10:15 GMT, Sebastian Lövdahl  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 two 
> additional commits since the last revision:
> 
>  - Remove unused `SELF_PID_NS`
>  - Rewrite in line with suggestion from Larry Cable

Hi Sebastian!

On 5/21/24 9:50 AM, Sebastian Lövdahl wrote:
>
> In these cases, is it not a requirement that jcmd is run as root?
> So even if the target process is run with elevated privileges,
> attaching would always work.
>

the constraint (as I understand it) is based upon the filesystem access 
to /proc//root/tmp, where the createAttachFile fails... if the 
"attacher" (jcmd) has access, if it has the
appropriate +og r/w access then it will be successful.

the "root" requirement comes from the default behavior of the container 
mgmt (docker) running containers as 'root'.

if you employ the --user option to 'force' the container to adopt a 
non-root identity jcmd will succeed if issued from the same 
user because it has r/w access to the /proc//root/tmp

note: if the container is in a distinct uid ns (from the attacher) I 
think the current checks performed by 
*os::Posix::matches_effective_uid_and_gid_or_root* will complete since 
the comparison is based on the uid values returned by the O.S 
(independent of the fact that the uid's may exist in distinct uid ns'es!)

> Or is there some way to attach from host to container with a
> non-root user that I'm missing?
>
> Or could it work in case the container is also run as a non-|root| user?
>

the use case I was addressing with my proposal is when the jcmd 
"container" (as a sidecar) is in the same pid ns as the target container 
but in a different mnt ns (I believe this is the regression use case) in 
that case falling back
to /tmp will not work and since the attacher and the attachee do not 
share a fs...

if the target JVM has elevated privs a (sidecar) attacher cannot use the 
target's /proc//root/... hence my experiment to recurse "up" 
the attachee's pid ns to look for a an un-privileged ancestor, which does
share the same mnt ns as the attachee, so the attacher can use the 
/proc//root/tmp to attach to the target... all things being 
equal...

Rgds

- Larry

> —
> Reply to this email directly, view it on GitHub 
> ,
>  
> or unsubscribe 
> .
> You are receiving this because you were mentioned.Message ID: 
> ***@***.***>
>

--XQdcZo9hO6wbcp2fGsjP1B9A
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit



  
  
Hi Sebastian!

On 5/21/24 9:50 AM, Sebastian Lövdahl
  wrote:


  
  
In these cases, is it not a requirement that jcmd
  is run as root? So even if the target process is run with
  elevated privileges, attaching would always work. 
  


the constraint (as I understand it) is based upon the filesystem
access to /proc/attachee/root/tmp, where the
createAttachFile fails... if the attacher (jcmd) has access, if 
it
has the
appropriate +og r/w access then it will be successful.

the root requirement comes from the default behavior of the
container mgmt (docker) running containers as 'root'.

if you employ the --user option to 'force' the container to adopt a
non-root identity jcmd will succeed if issued from the same
usergroup... because it has r/w access to the
/proc/attachee/root/tmp

note: if the container is in a distinct uid ns (from the attacher) I
think the current checks performed by os::Posix::matches_effective_uid_and_gid_or_root
will complete since the comparison is based on the uid values
returned by the O.S (independent of the fact that the uid's may
exist in distinct uid ns'es!)


  
Or is there some way to attach from host to
  container with a non-root user that I'm missing?
  
  Or could it work in case the container is also run
as a non-root user?


the use case I was addressing with my proposal is when the jcmd
container (as a sidecar) is in the same pid ns as the target
container but in a different mnt ns (I believe this is the
regression use case) in that case falling back
to /tmp will not work and since the attacher and the attachee do not
share a fs...

if the target JVM has 

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

[Sebastian Lövdahl]

> 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 two 
additional commits since the last revision:

 - Remove unused `SELF_PID_NS`
 - Rewrite in line with suggestion from Larry Cable

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/19055/files
  - new: https://git.openjdk.org/jdk/pull/19055/files/d3e26a0c..c57b4598

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk=19055=02
 - incr: https://webrevs.openjdk.org/?repo=jdk=19055=01-02

  Stats: 110 lines in 1 file changed: 59 ins; 14 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/19055.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19055/head:pull/19055

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