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