river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Thompson <br...@systap.com>
Subject Re: MarshalledObject, -Djava.rmi.server.useCodebaseOnly=false, stubs, Phoenix, Activation, RMIClassLoaderSPI
Date Mon, 28 Sep 2015 17:11:02 GMT
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 <jini@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.
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message