5 ms·
Of course you can deny it access to JNI [1]. The Java platform has had this built in since forever. This is how applets work. Aside from sandbox exploits classe
by spand 12y ago
Of course you can deny it access to JNI [1]. The Java platform has had this built in since forever. This is how applets work. Aside from sandbox exploits classes in Java can be locked down so much that they can pretty much only allocate memory and burn cycles.
[1] http://docs.oracle.com/javase/7/docs/api/java/lang/SecurityManager.html#checkLink%28java.lang.String%29 http://docs.oracle.com/javase/7/docs/api/java/lang/SecurityM...
- kllrnohj 12y agoJava Applets? That thing that had exploits like clockwork? Yeah, that worked great Regardless did you even bother looking at the documentation of SecurityManager? That would be a disaster to try and support. It can't clamp down per-library, it's all about current thread. Mods run in the same thread, they have to. So now you're suggesting that every. single. call into or out of a mod is guarded manually by updates to a permission manager that you are preventing the mod from modifying via reflection through... magic? Yeah, there's no way in hell that would ever work.