Yes, that's correct, Oracle has set it true by default to close a
security hole related to RMI, right now, River needs to set it back to
false in order to function. I've fixed this in my local copy of River.
The other reason it may be of concern is for RMIClassLoaderSPI providers
that aren't reachable from the application ClassLoader, such as in
Netbeans and OSGi, in these cases any classes resolved by
MarshalledObject or JRMP, would not be resolved via their configured
provider.
River-336 made changes to allow RMIClassLoaderSPI to be reachable from
other class loaders, but only for net.jini.io.MarshalInputStream
resolved classes, not those resolved from
sun.rmi.server.MarshalInputStream. JERI uses the former, while JRMP
uses the latter.
Regards,
Peter.
On 29/09/2015 3:11 AM, Bryan Thompson wrote:
Peter,
I assume that you want to set -Djava.rmi.server.useCodebaseOnly=true to
close a security hole, correct?
Thanks,
Bryan
On Mon, Sep 28, 2015 at 7:38 AM, Peter<[email protected]> wrote:
During my investigation into security, I realised wanted to set
-Djava.rmi.server.useCodebaseOnly=true.
To achive this I set about eliminating all generation of stubs in river,
related to download jar's, except for one specifically within Phoenix
itself, that was not downloaded, but was used by Phoenix locally.
All instances of creating MarshalledObject, or creating an object using
MarshalledObject.get() were replaced with MarshalledInstance.
In the qa-harness (not part of the tests), I also replaced JRMP with JERI.
After making these changes, I could set
-Djava.rmi.server.useCodebaseOnly=true.
My reason for mentioning this, was I recently realised that for River-336
Class loading is not used by MarshalledObject, instead MarshalledObject
uses RMI infrastructure.
Although it should probably be left until after River 3.0, I realise for
River-336 to completely Replace RMIClassLoader, we need to deprecate all
methods containing MarshalledObject (Apart from Activation constructors)
and provides alternative methods with MarshalledInstance in our api.
With this thought in mind, I considered the impact of Java 8 default
methods in interfaces. It turns out they provide a completely acceptable
method for interface evolution in River. For example, an earlier version
Service interface exists in the client, a service proxy implementing a
later interface default method is downloaded, in the client it will no
longer override the default method, as it doesn't exist in the client jvm,
this is still a binary compatible change, the proxy and client will be
compatible.
Working in the opposite direction, where a proxy from an earlier version
is downloaded into a client with a later version of the interface including
a default method, the combination will still be binary compatible.
Before reacting and rejecting this information, it's important for people
think of the consequences of not addressing this issue at some point.
Regards,
Peter.
