You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter <ji...@zeus.net.au> on 2015/09/28 13:38:58 UTC
MarshalledObject, -Djava.rmi.server.useCodebaseOnly=false, stubs,
Phoenix, Activation, RMIClassLoaderSPI
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.
Re: MarshalledObject, -Djava.rmi.server.useCodebaseOnly=false, stubs,
Phoenix, Activation, RMIClassLoaderSPI
Posted by Peter <ji...@zeus.net.au>.
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<ji...@zeus.net.au> 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.
>>
>>
Re: MarshalledObject, -Djava.rmi.server.useCodebaseOnly=false, stubs,
Phoenix, Activation, RMIClassLoaderSPI
Posted by Bryan Thompson <br...@systap.com>.
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 <ji...@zeus.net.au> 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.
>
>