#ReflectiveAccessByInstrumentationAgents

[Andrew Dinn]

Hi Peter,

On 06/05/16 15:34, Peter Levart wrote:
> On 05/06/2016 10:07 AM, Andrew Dinn wrote:
>> Not yet but I will do. n.b. for all practical purposes there is only one
>> Byteman module although which one it is depends upon whether the agent
>> jar is hoisted into the bootstrap or remains in the system loader. In
>> the former case the code is split but only in that the Main class gets
>> left in the system loader  while all others sit in bootstrap. Since Main
>> merely acts as a trampoline it does not require any special module linkage.
> . . .
> So if Main agent class is always loaded by bootstrap loader / unnamed

I am afraid you have that the wrong way around. An agent's Main class is
always loaded by the /system/ loader.

If requested, my agent's Main class will use method
appendToBootstrapClassLoaderSearch to place the agent jar file into the
bootstrap path, ensuring that /everything else/ is loaded by the
bootstrap loader. However, absent such a request it will retain the
status quo leaving /everything/ to be loaded by the system loader.

If I were able to split the agent code into two jars with a core jar
hoisted into the bootstrap and the rest of the code retained in the
system path then as you point out that would allow the core jar to
include classes which do stuff that is normally restricted. This might
also allow me to ensure that the API classes were in the right place
while leaving the rest of the agent in the system path. I'm not sure if
I can achieve this sort of split (using some combination of dynamic
loading and interfaces) but I think it would probably require some
significant changes to achieve it.

My main problem with that is not the refactoring it would require but
the fact that Byteman would need to know where the core jar is located
in order to hoist it -- the Instrument API to extend the bootstrap path
takes a path to the jar in the file system. So, users would have to
configure this as an agent option on the -javaagent command line or as
an argument to the utility that loads the agent dynamically. This extra
configuration is already required when users want the current agent jar
to be hoisted -- but it's actually turned out to be a noticeable barrier
to uptake (many users don't really understand what the difference
between the boot and sys loaders is, never mind how link requirements
constrain adding jars to one or other). Requiring them to configure a
different jar in the default case risks making normal use problematic
for many users.

One possibility I am still considering is to synthesize the class I
require to do the restricted accesses and write it to a jar file in a
tmp dir. I could then access it via the bootstrap loader and create an
instance which I could then use to obtain the desired access. That might
be a better option although I am still thinking about the security
implications.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander