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