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: Distributed Garbage Collection & Security - InvocationConstraints
Date Sun, 31 Jul 2011 10:35:04 GMT
Peter Jones wrote:
> On Jun 19, 2011, at 5:37 AM, Peter Firmstone wrote:
>> The easiest way to set DGC constraints would be via configuration.
>> Perhaps the reason this hasn't been implemented previously is, the constraints would
apply to all services that use DGC, so if you've set Authentication and Integrity as minimal
constraints, then this would apply to all services.
> As mentioned offline, I'm not sure how much of this I can page into my consciousness
at the moment.
> Configuring the server-side constraints for DGC could probably be supported with additional
parameters to the export process (and thus set via configuration).  The bigger issue, I think,
is what client constraints to apply, and what client subject to use, when JERI's client-side
DGC system (defined within BasicObjectEndpoint) makes "dirty" and "clean" calls on behalf
of the application.  In the traditional RMI DGC model, those calls happen implicitly as remote
references appear and disappear from a JVM.  But in the JERI security model, the client application
controls the security behavior of remote calls by explicitly (with respect to the standard
JERI layers) specifying constraints and controlling the current subject.
> So when the system wants to make a "dirty" or "clean" call for a given remote reference
(forget batching for the moment), what constraints to apply, or what subject to use?  There
didn't seem to be an answer, without requiring the client application to interact with the
DGC system more explicitly, which would be a significant change from the RMI DGC model-- and,
I think, not something that seemed worth investing effort on at the time, especially given
that Jini services didn't seem to make use of RMI's DGC functionality in practice anyway (instead
they used higher-level leasing mechanisms to detect client "failure", and most interest was
around just being disable DGC for Jini services).

Having thought about it, something with similar behaviour to a local 
JVM's gc would be appropriate, for example, if code with higher 
privilege allows a reference to escape into less privileged code, the 
garbage collector won't collect it until it becomes unreferenced by all 

So it would seem appropriate to cache the first Subject (or Subjects) 
who've called methods on the remote object and use it (them) for the DGC 
client Subject.  Different Target's might have different Subject's, so 
we could perform Subject orientated batching.

The unprivileged code, wouldn't be able to call methods that had 
constraints, similar to how an object with method guards works, however 
any code that holds a strong reference would prevent that object from 
being garbage collected.

I think this would be useful in an internet environment, where a 
developer wants to export an object and hand it as a parameter to 
another service, and have it unexported automatically when no longer 



>> Exporter's javadoc has the following statement regarding the force parameter in unexport:
>> <QUOTE>
>> The |force| parameter serves to indicate whether or not the caller desires the unexport
to occur even if there are known remote calls pending or in progress to the remote object
that were made possible by this |Exporter|:
>>   * If |force| is |true|, then the remote object will be forcibly
>>     unexported even if there are remote calls pending or in progress,
>>     and this method will return |true|.
>>   * If |force| is |false|, then this acts as a hint to the
>>     implementation that the remote object should not be unexported if
>>     there are known remote calls pending or in progress, and this
>>     method will either unexport the remote object and return |true| or
>>     not unexport the remote object and return |false|. If the
>>     implementation detects that there are indeed remote calls pending
>>     or in progress, then it should return |false|; otherwise, it must
>>     return |true|. If the implementation does not support being able
>>     to unexport conditionally based on knowledge of remote calls
>>     pending or in progress, then it must implement this method as if
>>     |force| were always |true|.
>> If the remote object is unexported as a result of this method, then the implementation
may (and should, if possible) prevent remote calls in progress from being able to communicate
their results successfully.
>> </QUOTE>
>> I've updated the class Target that implements this functionality for BasicJeriExporter,
Target's unexport method now uses thread interruption to attempt to interrupt and abort in
process calls if force is specified.  Interruption has been successful with the current jeri
qa tests and can be seen in the exception output for some tests.
> FWIW, aborting the execution of in-progress calls, such as via thread interruption, wasn't
really the intent of that last sentence-- it was more that an implementation should feel free
(or encouraged) to prevent communicating the eventual result of such a call, when control
of the dispatching thread is returned to this layer of the system.
> Cheers,
> -- Peter

View raw message