river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy
Date Mon, 13 Feb 2017 13:15:27 GMT
So this object that you have with a locally installed class is tasked with authenticating the
remote service, provisioning and resolving a bundle, deserializing the smart proxy and registering
it with the OSGi service registrar in a readResolve or readObject method?

How do you propose the connection from the client to the service established in order to enable
this to occur?

How do you prevent an attacker from choosing a different class to deserialize?



Sent from my Samsung device
  Include original message
---- Original message ----
From: Michał Kłeczek <michal@kleczek.org>
Sent: 13/02/2017 10:07:28 pm
To: dev@river.apache.org
Subject: Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

Comments inline. 

Peter wrote: 
> Mic, 
> I'm attempting to get my head around your proposal: 
> In the case of JERI, the InvocationHandler is part of the smart  
> proxy's serialized state.  A number of smart proxy classes will need  
> to be unmarshalled before the UnmarshallingInvocationHandler is  
> deserialized. 
> The smart proxy contains a reference to a dynamic proxy (which sun  
> called the bootstrap proxy) and the dynamic proxy contains a reference  
> to your UnmarshallingInvocationHandler.    This means the smart proxy  
> must be unmarshalled first. 
> How do you get access to UnmarshallingInvocationHandler without  
> unmarshalling the smart proxy first? 

No no - I am saying about wrapping the smart proxy inside another  
object. It can be either a dynamic proxy, or simply an object that  
implements "readResolve" returning the unmarshalled smart proxy. 

> More comments inline below. 
> On 13/02/2017 6:11 PM, Michał Kłeczek wrote: 
>> We are talking about the same thing. 
>> We are turning circles, Peter - all of this has been already discussed.

>> 1. Yes - you need to resolve bundles in advance (in OSGi it is not 

>> possible to do otherwise anyway) 
> Agree. 
>> 2. You cannot decide upon the bundle chosen by the container to load 

>> the proxy class (the container does the resolution) 
> Disagree, nothing in the client depends on the proxy bundle, there's  
> no reason to provision a different version. 
>> 3. The runtime graph of object places additional constraints on the 

>> bundle resolution process (to what is specified in bundles' manifests).

>> Since you do not have any way to pass these additional constraints to 

>> the container - the case is lost. 
> Disagree.  The proxy bundle contains a manifest with requirements.   
> The stream has no knowledge of versioning, nor does it need to, there 

> are no additional constraints.  If the service proxy dependencies  
> cannot be resolved, or it doesn't unmarshall, then it will not be  
> registered with the OSGi registry in the client, client code will not  
> discover it and the client will have no knowledge of it's existance  
> except for some logging. 
This is totally backwards. 
That way no client is able to find any service because there is a  
chicken and egg problem - we do not know the proxy interfaces until the  
proxy's bundle is resolved. 

Understand that when you place a bundle identifier in the stream - it is  
equivalent to specifying a Require-Bundle constraint - nothing more  
nothing less. 

>> Additionally - to explain what I've said before about wrong level of 

>> abstraction: 
>> Your general idea is very similar to mine: have a special object  
>> (let's call it installer) that will install software prior to proxy 

>> unmarshalling. 
>> 1. For some reason unclear to me you want to constrain the way how 

>> this "installer object" is passed only via the route of  
>> ServiceRegistrar (as attributes) 
> Disagree, I'm not proposing the service have any control over  
> installation at the client, other than the manifest in the proxy  
> bundle, nor am I proposing using service attributes, or the use of any 

> existing ServiceRegistar methods (see SafeServiceRegistrar link posted  
> earlier). 
If you think about it from the higher architectural view - there is no  
difference. It does not really matter what steps are made - important  
thing is that: 
a) you have a special object used to download code - this object is  
supposed to be of a class installed locally in advance 
b) the above object is used to create a ClassLoader that you will use it  
load the actual deserialized object's class 

It does not matter where the first object is taken from - be it  
"SafeServiceRegistrar", the stream itself, a JavaSpace or the Moon. 


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