VirtualMachine in tools.jar

Andrew Dinn adinn at redhat.com
Tue Aug 25 09:12:50 UTC 2015


On 25/08/15 08:58, Alan Bateman wrote:
> If I understand Henri's mail correctly then he is advocating that the
> attach API be included in the JRE builds. The attach API was developed
> as an API for tools so this is why it has always been in the JDK builds
> and not the JRE builds. Maybe there are new use-cases now that mean it
> should be re-examined but it's not clear from the original mail. In
> general, there are many interesting tools and tool APIs in the JDK
> builds that might sometimes be useful in environments that only have a
> run-time installed so I guess a similar argument could be made for those
> too.

I think the attach classes are a very special case and there are
extremely important security reasons for not having the attach API
classes in the JRE as the normal case. Their presence in a runtime poses
the threat of exploding a small security hole into a gaping breach
(since the attach mechanism could be used by rogue code to install a
JVMTI Java agent into the current JVM -- with game over consequences).
Any runtime that is going to load code that needs to be constrained
(e.g. a browser running stuff like applets) probably doesn't want these
classes to be in the runtime. I know there are other ways of restricting
access but I believe the status quo is belt and braces.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters
(USA), Michael O'Neill (Ireland)


More information about the jdk9-dev mailing list