<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 30/04/2023 23:24, Ron Pressler
wrote:<br>
</div>
<blockquote type="cite" cite="mid:41BFCE0A-AE21-468B-8CF0-57710034845C@oracle.com">
<div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode:
space; line-break: after-white-space;" class="">
Hi Mike!<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 30 Apr 2023, at 19:59, Mike Hearn <<a href="mailto:mike@plan99.net" class="moz-txt-link-freetext" moz-do-not-send="true">mike@plan99.net</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<blockquote type="cite" class="">we’ve begun to explore
means other than the flag to allow a tool to load an
agent at runtime<br class="">
</blockquote>
<br class="">
How about restricting access to the jcmd socket. For
in-VM code it can<br class="">
be blocked at the filesystem implementation level, and
for<br class="">
sub-processes by using the operating system APIs to
determine if the<br class="">
other side of the socket is part of the same process
tree at connect<br class="">
time. This would avoid the need for new UI to re-enable
existing jcmd<br class="">
functionality, whilst preventing code loaded into the VM
from<br class="">
connecting back to that same VM. Only truly external
tools could<br class="">
trigger agent loading, or modules that had been given
permission to do<br class="">
that.<br class="">
<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Determining the process on the other side and/or
maintaining the integrity of the process tree is not easy on
all OSes.</div>
<br>
</div>
</div>
</blockquote>
<br>
Right, it's feasible to get the peer pid on some platforms but you
can't rely on the process tree due to re-parenting when a parent
terminates.<br>
<br>
-Alan<br>
</body>
</html>