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
