Instrumentation API: module -> class loader with a security manager

2016-04-28 Thread Rafael Winterhalter
I noticed a small obstacle while porting code to the Java 9 instrumentation
API. It is now required to pass by a security manager to read the class
loader from the module (via Module::getClassLoader).

This was not required using the old API. In this sense, it is not really
more secure since I can always fall back to the old API but I need to ask a
user for an additional privilege that I did not need before if I want to
use the new API and a security manager is active.

Would it make sense to provide the class loader as an additional argument
in the new instrumentation API to avoid this?


Re: Instrumentation API: module -> class loader with a security manager

2016-04-28 Thread Alan Bateman

On 28/04/2016 13:22, Rafael Winterhalter wrote:

I noticed a small obstacle while porting code to the Java 9 instrumentation
API. It is now required to pass by a security manager to read the class
loader from the module (via Module::getClassLoader).

This was not required using the old API. In this sense, it is not really
more secure since I can always fall back to the old API but I need to ask a
user for an additional privilege that I did not need before if I want to
use the new API and a security manager is active.

Would it make sense to provide the class loader as an additional argument
in the new instrumentation API to avoid this?

We have this listed in JDK-8155207 [1] to look at. RĂ©mi brought this up too.

In some sense then all bets are off when you run with an agent as it can 
manipulate bytecode to bypass permission checks. In other words, 
granting anything less than AllPermission may not make the environment 
any more secure.


-Alan

[1] https://bugs.openjdk.java.net/browse/JDK-8155207