<!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>