.... On 6 February 2011 06:31, Peter Firmstone <j...@zeus.net.au> wrote:
> I've refactored Proxy Isolation and added return value checks, to ensure > that remote code cannot be passed to the calling thread. > > It's basically just an invocation handler to be used for creating a > reflective proxy that can be used to pass method calls to a smart proxy, > isolated in it's own thread and ClassLoader. > > The caller communicates with the remote code using method invocation, > return values are checked to ensure remote code does not escape thread > isolation. > > The basic idea behind this class is: > > On the internet, you might find a service (with a smart proxy) your > interested in, but you don't know and cannot authenticate its subject. > Since purely reflective proxy's on the internet will probably experience > some latency issues, it's more practical to allow execution of remote code > locally. > > Is that sufficient justification for this or should we be looking to spec things so that one can authenticate etc if it's important or otherwise just proceed as usual? Dunno, thinking out loud but my stock approach is to see about the specs before worrying about code... > By isolating the smart proxy within it's own thread and classloader, the > smart proxy has no permissions, other than those required to communicate > with it's originating server, it cannot cause a StackOverflowError, all it > can do is consume it's own thread, the calling thread can catch a > TimeoutException and continue. I'm thinking of encapsulating any Exceptions > in a RemoteException, so existing clients can utilise it. > > This might leave a background daemon thread for some time if code is > malicious, eventually it will experience a stack overflow and be terminated > (if stuck in an endless loop) or be interrupted, but since these threads > have low priority, they can't do much harm, the number a box can withstand > and continue running, depends on how much memory it has, whether it's > running a 64 bit jvm and what the thread stack size is. > > > Cheers, > > Peter. > >
