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

[Francois]

On 23/07/2018 15:43, Roger Riggs wrote:
> Hi Francois,
>
> [The core-libs-dev at openjdk.java.net would also be a good mail list for 
> the discussion.]
>
> There is no simple solution to stopping runaway computations and 
> retaining the integrity
> of the remaining system but there are mitigations that can 
> incrementally reduce the impact.
>
> If you control the scripting language that is exposed, you can build 
> in checkpoints
> for runaway cpu consumption. Lightweight checks such as elapsed clock 
> time (System.nanoTime)
> can be used to periodically check for accumulated cpu time, and other 
> resource excessive usage.
>
> Impact on other processes can be reduced by throttling the computation 
> by introducing
> wait times to avoid exceeding some threshold of the ratio between 
> cputime and clock time.
> Depending on what's in the loop, throwing InterruptedException may 
> sufficiently disrupt
> the loop so it terminates.
> If the script is really while(true){}; then perhaps the interpreter 
> can flag that as a potential bug.
>
> Regards, Roger

Thanks,
Unfortunatly I don't have a hand on the underlying scripting engine / 
language (it's just nashorn/js). But I can totally add a sanity check at 
least for trivial loops. I will keep the idea, thanks !


>
>
> On 7/23/18 8:55 AM, Francois wrote:
>> 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