Return-Path: 
 <river-dev-return-4822-apmail-incubator-river-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-river-dev-archive@minotaur.apache.org
Received: (qmail 1241 invoked from network); 11 Oct 2010 14:18:17 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 11 Oct 2010 14:18:17 -0000
Received: (qmail 77170 invoked by uid 500); 11 Oct 2010 14:18:17 -0000
Delivered-To: apmail-incubator-river-dev-archive@incubator.apache.org
Received: (qmail 77052 invoked by uid 500); 11 Oct 2010 14:18:16 -0000
Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:river-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:river-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:river-dev@incubator.apache.org>
List-Id: <river-dev.incubator.apache.org>
Reply-To: river-dev@incubator.apache.org
Delivered-To: mailing list river-dev@incubator.apache.org
Received: (qmail 77044 invoked by uid 99); 11 Oct 2010 14:18:15 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 14:18:15 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: local policy)
Received: from [89.161.231.213] (HELO v046695.home.net.pl) (89.161.231.213)
    by apache.org (qpsmtpd/0.29) with SMTP; Mon, 11 Oct 2010 14:18:07 +0000
Received: from 87-205-150-195.adsl.inetia.pl [87.205.150.195] (HELO
 mkleczek-laptop.localnet)
 by xpro.home.pl [89.161.231.213] with SMTP (IdeaSmtpServer v0.70)
 id 1a1187f00a63f01e; Mon, 11 Oct 2010 16:17:52 +0200
From: Michal Kleczek <michal.kleczek@xpro.biz>
Organization: XPro Sp. z o. o.
To: river-dev@incubator.apache.org
Subject: Re: Towards Internet Jini Services (trust)
Date: Mon, 11 Oct 2010 16:17:43 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.31-22-generic; KDE/4.4.2; x86_64; ; )
References: <4C9DB5BF.8090307@zeus.net.au> <4CB3127D.10409@zeus.net.au>
 <4CB3141A.5000504@zeus.net.au>
In-Reply-To: <4CB3141A.5000504@zeus.net.au>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201010111617.43428.michal.kleczek@xpro.biz>

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).

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)."

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.

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.

Michal