river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Towards Internet Jini Services (trust)
Date Mon, 11 Oct 2010 22:27:12 GMT
Michal Kleczek wrote:
> On Monday 11 of October 2010 15:41:46 Peter Firmstone wrote:
>   
>> What about the case where a Module depends on another Module?
>>
>> I'm guessing that was the intent.
>>
>>     
>
> Actually - no :)
>
> There are two different things to consider:
>
> 1. Module dependencies (which I actually did not think about too much).
>   

Actually I'm thinking there shouldn't be any dependencies, other than 
the Jini Platform and ServiceAPI, which has been used to obtain the 
Module.  In fact the Module is a handler for the Proxy Namespace 
(sandbox), the ClassLoader returned by getClassLoader(Subject s) will 
know which ClassLoader is used within the proxy namespace, if there is 
more than one ClassLoader for that Subject.

We could rename Module to ProxyNamespace?


> and
> 2. The client gets a proxy and this proxy code causes downloading objects 
> annotated with a different Module than the proxy's Module (IOW downloading 
> subsequent Modules happens _after_ the proxy was deserialized, prepared and 
> granted permissions). We need a way to say:
> "OK I've downloaded some code, an object, verified that I trust both the code 
> and this object - now I don't really care how it is implemented - I trust that 
> if it needs to download some more code - it already was verified)."
>   

Actually we don't need to do that if the annotation is a reflective 
proxy, since it is deserialized using only local code.

> That is something that can be achieved with DelegatedModuleTrustVerifier - the 
> client can grant DownloadPermission to the proxy it just deserialized and 
> prepared. Note that it is not transitive - the client has to grant a 
> GrantPermission(new DownloadPermission()) to the proxy if it wants the 
> DownloadPermission to be transfered further.
>   

If the annotation is a reflective proxy, namely ModuleServiceProvider, 
we verify it, get the CodeSource, for the Module from it, using only 
local code, at this point in time the Module proxy doesn't exist, we 
grant DownloadPermission to the CodeSource (it's jar file hasn't yet 
been downloaded). This only permits download of the jar file.

Then we ask the ModuleServiceProvider for the Module Object and 
deserialize it using a ClassLoader we just created.

We then verify the Module and grant it GrantPermission(DownloadPermission).

The Module can now download any CodeSource's required by our service 
proxy, which has yet to be unmarshalled, the Module has to grant 
DownloadPermission to each CodeSource it wants to download.  Remember 
the proxy doesn't know it's CodeSource, the Module does.  We trust the 
Module not to abuse the trust we have just granted.

If the service proxy returns another service proxy, it will be annotated 
with it's own ModuleServiceProvider and the whole process repeats.

The Module is the package handler the Service gets to dynamically inject 
into the client to organise it's proxy namespace.

> All is good so far except that the proxy must postpone deserialization of 
> subsequent objects so that it happens after the client had a chance to grant 
> permissions to the proxy.
> With my proposal nothing really changes in a way the client handles objects 
> that it receives - permissions are granted to the proxy in exactly the same 
> way as it is done in Jini 2.1.
>
> So unfortunatelly if we have a proxy:
> class MyProxy implements Serializable {
>   private JavaSpace space;
>   //
> }
> it would have to be changed to:
> class MyProxy implements Serializable {
>   private MarshalledObject<JavaSpace> marshalledSpace;
> }
> if the service wants to make use of DownloadPermission that was possibly 
> granted to it by the client.
>
> Sure - it would be cool if we could grant permissions earlier (as soon as a 
> Module is verified and the ClassLoader is created) but I just don't know how 
> the client would pass the permissions it wants to grant to a Module to the low 
> level deserialization code.
>   

We only grant DownloadPermission, to each CodeSource, the proxy will 
inherit the DownloadPermission from it's CodeSource, but it can't use it 
to go and download another CodeSource. The proxy doesn't yet exist, when 
we grant the DownloadPermission. We delay all other Permission's granted 
to the proxy until it is verified, when the permissions can be directly 
negotiated between the proxy and client.

This process will be the same, no matter what the service proxy being 
unmarshalled is.

> Michal
>
>   


Mime
View raw message