Always communicating in a separate JVM is going to have obvious performance costs. Do we know what they are and are they acceptable? Is going to be easy to turn off for.people who trust what they're downloading an don't want to pay the perf costs etc?
On 11 Jun 2011 20:49, "Peter Firmstone" <[email protected]> wrote: > Dan Creswell wrote: >> On 8 June 2011 05:31, Peter Firmstone <[email protected]> wrote: >> >>> Phoenix wakes (Activates) up a Service when it's required on the server >>> side. I haven't thought of a good name for it, but unlike Phoenix, the >>> concept is to perform discovery, lookup and execute smart proxy's on behalf >>> of the client jvm at the client node, although I concede you could run a >>> service from it also. Reflective proxy's would be used to make smart >>> proxy's appear to the client as thought they're running in the same jvm. >>> >>> Process has some peculiarities when it comes to input and output streams, >>> they cannot block and thus require threads and buffers to ensure io streams >>> are always drained. Process uses streams over operating system pipes to >>> communicate between the primary jvm and subprocess jvm. >>> >>> I've been toying around with some Jeri endpoints, specifically for Process >>> streams and pipes, still I'm not sure if I should consider it a secure >>> method of communication just because it's local. Do you think I should >>> encrypt the streams? >>> >>> >> >> So you want to use pipes? >> >> The answer to whether you want to encrypt the streams or not is down >> to what kind of threat you're trying to mitigate. And the threats >> possible are determined by what solution you adopt. Pipes are >> basically shared memory, what kind of attacks are you worrying about >> in that scenario? >> > > I guess the attacker would be someone who already has user access to a > system, if that's the case, the game's probably lost for most systems. > > I'm trying to consider the semantics of such a connection with regard to > InvocationConstratints. > > Integrity, > Confidentiality, > ServerAuthentication > ClientAuthentication. > > It really doesn't support any of the above constraints, but we're not > going to use it for discovery etc.. > > The intended purpose is to isolate downloaded code in a separate jvm and > communicate with it using a reflective proxy. > > >> >>> Cheers, >>> >>> Peter. >>> >>> >> >> >
