#ReflectiveAccessByInstrumentationAgents

[Paul Benedict]

I prefer the originally-proposed addExports() but allowing the layer to
authorize it -- with a security check or other custom constraint the
implementer chooses to code.

Cheers,
Paul

On Fri, May 6, 2016 at 9:34 AM, Peter Levart <peter.levart at gmail.com> wrote:

> Hi,
>
>
> On 05/06/2016 10:07 AM, Andrew Dinn wrote:
>
>> >Have you looked at injecting code in the victim module that invokes
>>> >Module addExports to export the packages to the Byteman modules (modules
>>> >plural because it sounds like the code is split between the unnamed
>>> >module of the app class loader and the unnamed modulie of the boot
>>> loader).
>>>
>> 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.
>> regards,
>>
>>
>> Andrew Dinn
>>
>
> So if Main agent class is always loaded by bootstrap loader / unnamed
> module, what about an API point in Instrumentation like:
>
> void addModuleExportsToBootstrapUnnamed(Module module, String pn);
>
> This would only allow adding exports from arbitrary module / package to
> bootstrap unnamed module, which would contain (part of) agent. This part of
> agent could also contain trampolines with regulated access from
> instrumented / tested classes. Every call to such exposed code would have
> to be done by invocation through Byteman layer then which could regulate
> access by any means including but not limited to exporting the Byteman code
> package to selected set of modules.
>
> Such limited addExports API would not allow to break encapsulation in
> arbitrary ways.
>
> Regards, Peter
>
>