Force *Untrusted* Thread to Stop

Question

My application is running untrusted code from an external source and must force it to stop after a certain amount of time. At first I thought I would cheat and call the deprecated method Thread.stop(). I am aware of the dangers in calling Thread.stop(), but all of the alternatives to Thread.stop() that I have found assume control over the thread being stopped, which is not the case with my application. However, even this will not work because the untrusted code could start its own thread with an infinite loop, and I would not have access to that thread to be able to stop it.
The only way I can think to handle this is to start a new OS process, with a new JVM, just to run the thread. When I want to terminate the thread I can simple call System.exit() from within that virtual machine. Is there a less resource-intensive solution?
I have no moral objection to using Thread.stop() to solve this; the untrusted code will run with a SecurityManager tightly controlling its access to resources, so I am not worried about the problems described in the deprecation explanation of Thread.stop() (and even if there are problems, they would have to be big problems to be worse than starting 1 million infinite loops and choking my server). For instance, is there a way to produce all the descendant threads produced by a given thread? Is there a sandbox in which the code can be run (and stopped at my command) that is lighter than an entirely new virtual machine?
Thank you,
Dave

Answer 1

If the unsafe code could start a thread I suggest your thread should be in a new ThreadGroup which you can use to shutdown all threads that get created.
pexatus wrote:
alan_mehio wrote:
Hi,
The stop method has been deprecated and it is not recommended to be used since it is not safe. your code is working because of the backward compatiblity ( still works on Java 6). Again this method should not be used since it causes to unlock all the monitors by this thread and it may keep the locked objects by this thread with an unconsistant state. I understand that Thread.stop() is deprecated and unsafe in the general case where the Thread being stopped can do anything. Since the untrusted code I am running can be locked down with a SecurityManager, it seems as if there should be a way to lock it down enough that the problems inherent in Thread.stop() will not appear.You have to test it to see. It may be that there is a small but acceptable leak. How often do you restart your application?
To use your example (which is also the only example I can find online for why not to use Thread.stop(), though other unstated examples may invalidate my claim), if the code in the Thread cannot access any object that was not created within that Thread or one of the Threads running under its ThreadGroup, and if my code does not attempt to access any of those objects, then it is not a problem to leave those objects in an inconsistent state. Since any thread that might be using them will be stopped at the same time, it will not matter that the objects are inconsistent.The problem I believe is resources which require an explicit call to be made to clean them up. This includes Threads, Sockets, Files (including log files), JDBC resources. If you kill a process, all reaources get cleaned up by the OS, but if you kill a thread, there is no guarantee any of these resources will be cleaned up.
>
Now you are executing another application inside you application which is not safe.Then what is the purpose of the Java security model? I thought that the whole premise was that untrusted code could be run. The examples online are largely about running untrusted applets over the internet on a trusted client browser, but I see no reason I cannot use the same idea to secure a part of my application.The security model applies globally, not just your untrusted code. Any operation you allow for your application to operate is a security whoel for your untrusted code to exploit.
>
What is the relation of a thread with the application execution.
Does the unsafe application get executed inside a sepearate thread from your main application? if yes , have you thought of using ExecutorService where you can submit a Callable into the executor service and it returns a Future. You can cancel the returned Future.Canceling the returned Future uses Thread.interrupt to try to stop the thread. Using Thread.interrupt requires control over the code being interrupted. Since I don't have control over the code being interrupted, I cannot use it. I don't get that. If you are willing to kill the thread, I don't see the problem with give the thread a chance to shutdown gracefully. I have found that an interrupt does stop many third party threads and so I give the thread a few second to shutdown (interrupt followed by a join with a timeout) and only kill it if it doesn't.
Try creating a FutureTask with an infinite loop (without any polling of the interrupted status of the Thread) and canceling it after it has gotten started; it will not, in fact, be canceled.
If anyone knows of a way to stop code over which I do not have control, without using Thread.stop(), then I would appreciate hearing about it. The only way I can think of is to run a separate JVM, and kill it with System.exit, but as I said, this has much overhead.Another option is to use reflection hack an internal variables/methods which would shutdown the thread. This would require some investigation (such as a debugger) which I have found usually leads me to some undocumented/poorly documented public method. :)