<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    so I think to summarize the logic we require:<br>
    <br>
    1) if we can determine that the attacher and attachee occupy the
    same mnt ns (/proc/<attacher>/ns/mnt ==
    /proc/<attachee>/ns/mnt), return "/tmp"<br>
    2) if they are not in the same mnt ns:<br>
        - test the /proc/<attachee>/root/tmp path for readability,
    if it is, return that<br>
        - if it is not readable (its either secured with elevated privs
    and it exists) return "/tmp" which may still fail because they are
    in fact not in the same mnt ns<br>
    <br>
    what about /proc/<attachee>/cwd?<br>
    <br>
    - Larry<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/3/24 9:43 AM, Sebastian Lövdahl
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:openjdk%2Fjdk%2Fpull%2F19055%2Fc2093378574@github.com">
      
      <p dir="auto">Thanks for the patch <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/larry-cable/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://urldefense.com/v3/__https://github.com/larry-cable__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5xDccS1BA$" moz-do-not-send="true">@larry-cable</a>, much appreciated! I
        really like this idea.</p>
      <p dir="auto">I tried it out a bit locally. These cases seem to
        work:</p>
      <ul dir="auto">
        <li>attaching to a process running on the same host (PID and
          mount namespace the same)</li>
        <li>attaching as root from the host to a JVM inside a container</li>
        <li>attaching from a sidecar container to a JVM in another
          container</li>
      </ul>
      <p dir="auto">Unfortunately, attaching to a JVM process running as
        the same user in the same PID and mount namespace but one that
        has elevated privileges no longer works (the case that
        JDK-8226919 fixed). That case ends up failing like this with the
        patch:</p>
      <pre class="notranslate"><code class="notranslate">slovdahl@ubuntu2204:~/reproducer$ /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd 1751545 VM.version
1751545:
java.io.IOException: Unable to access root directory /proc/1751545/root of target process 1751545
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:284)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:229)
        at jdk.attach/sun.tools.attach.VirtualMachineImpl.<init>(VirtualMachineImpl.java:86)
        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)
</code></pre>
      <p dir="auto">I <em>think</em> it boils down to the same reason
        as why the fix for JDK-8226919 was needed in the first place - a
        non-root user cannot read the symlinks in <code class="notranslate">/proc/<pid>/ns</code> for a process
        running with more privileges even though it's run by the same
        non-root user.</p>
      <pre class="notranslate"><code class="notranslate">slovdahl@ubuntu2204:/proc/1751545/ns$ ls -lh
ls: cannot read symbolic link 'net': Permission denied
ls: cannot read symbolic link 'uts': Permission denied
ls: cannot read symbolic link 'ipc': Permission denied
ls: cannot read symbolic link 'pid': Permission denied
ls: cannot read symbolic link 'pid_for_children': Permission denied
ls: cannot read symbolic link 'user': Permission denied
ls: cannot read symbolic link 'mnt': Permission denied
ls: cannot read symbolic link 'cgroup': Permission denied
ls: cannot read symbolic link 'time': Permission denied
ls: cannot read symbolic link 'time_for_children': Permission denied
total 0
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 cgroup
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 ipc
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:27 mnt
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 net
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid_for_children
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time_for_children
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 user
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 uts
slovdahl@ubuntu2204:/proc/1751545/ns$ sudo ls -lh
total 0
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:27 mnt -> 'mnt:[4026533862]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 net -> 'net:[4026531840]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 pid_for_children -> 'pid:[4026531836]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time -> 'time:[4026531834]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 time_for_children -> 'time:[4026531834]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 user -> 'user:[4026531837]'
lrwxrwxrwx 1 slovdahl slovdahl 0 maj  3 19:28 uts -> 'uts:[4026531838]'
</code></pre>
      <p dir="auto">FWIW, my IntelliJ also highlighted the fact that the
        suggested patch contains unreachable code. The <code class="notranslate">else throw new
          IOException(String.format("target process:%d and this do not
          share common mount namespace for: %s attach failed", pid,
          tmpdir));</code> path can never be taken, because either the <code class="notranslate">if</code> statement evaluates to <code class="notranslate">true</code>, or the <code class="notranslate">else if</code>.</p>
      <p dir="auto">I'm not sure if we can do any better than always
        falling back to <code class="notranslate">/tmp</code>? But if
        anyone has suggestions, I'm certainly happy to try it out.</p>
      <p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br>
        Reply to this email directly, <a href="https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/19055*issuecomment-2093378574__;Iw!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wAeEv03g$" moz-do-not-send="true">view it on GitHub</a>, or <a href="https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ANTA67UD2AU4WJYYSI7427LZAO5CTAVCNFSM6AAAAABHDNNTT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGM3TQNJXGQ__;!!ACWV5N9M2RV99hQ!J0KoDI4DkLNZ2JvWqbMeoXL5IFCiU97HRtB_b7i_B3cyEAzJPRDxISuGqYNLzapuMPcnSApQyL_CNtLiA5wuDyNaeA$" moz-do-not-send="true">unsubscribe</a>.<br>
        You are receiving this because you were mentioned.<img src="https://github.com/notifications/beacon/ANTA67Q46VGFEYWUVI36CN3ZAO5CTA5CNFSM6AAAAABHDNNTT6WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTT4YZWA4.gif" alt="" moz-do-not-send="true" width="1" height="1"><span style="color: transparent; font-size: 0; display: none; visibility: hidden; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0; mso-hide: all">Message
          ID: <span><openjdk/jdk/pull/19055/c2093378574</span><span>@</span><span>github</span><span>.</span><span>com></span></span></p>
      <script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2093378574",
"url": "https://github.com/openjdk/jdk/pull/19055#issuecomment-2093378574",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
    </blockquote>
    <br>
  </body>
</html>