Thread.strop removed: how to deal with a rogue ScriptEngine thread?

Francois fanf42 at gmail.com
Mon Jul 23 12:55:58 UTC 2018


Hello,

I'm not sure at all it is the correct mailing list for that, so sorry if 
it is not, and please let me know where I should post my concerns.

So, in JDK 11, the long term deprecated Thread.stop() will is removed 
(https://bugs.openjdk.java.net/browse/JDK-8204243), and I have an use 
case that I don't know how to deal with afterwards.

We use nashorm to provides user with a embeded scripting languageon our 
plateform. Only simple things are accessible, and we try to forbid 
dangerous things like killing the host process, deleting the underlying 
filesystem, or infinite, not pause-to-look-for-Thread.interrupt while 
loops.
The first two kind of problem are easely managed with a custom security 
manager and a thread factory that uses itfor starting the sandboxed 
process (ie: nashorn.eval).

But I don't know how to manage the while(true){} loop. In that case, the 
nashorn thread does not respond to Thread.interrupt (it is a wide source 
of surpise and wonders on the internet, see for example: 
https://stackoverflow.com/questions/1601246/java-scripting-api-how-to-stop-the-evaluation/1601465#1601465 
and the problem is more generally that Java ScriptEngine API does not 
provide a way to interrupt underlying process ounce started). So I used 
to have a timeout counter and a Thread.stop() on it. Ido understand that 
it could still raise problems, even with the custom threadfactory and 
the very specific use case, but it was the only solution I knew of at hand.

But now, I don't have any at all to prevent an user to start unstoppable 
thread (by malice or by error).

Any help would be much appreciated on that topic.

-- 
Francois ARMAND - @fanf42
https://github.com/Normation/rudder
http://www.normation.com



More information about the discuss mailing list