Adding support to extend CopyStrategyLibrary through modules

Cpt. Crispy Crunchy

Member
Contributor
Hey,

I struggled for quite some time and on different occasions now to be conform with supported types in the said libraries. Unfortunately there were only complicated workarounds as solution yet and it slowed development significantly for me.
Especially since it is not easy to add module specific CopyStrategies through some access protection with @RegisterCopyStrategy . (You can't define those outside the engine package it seems).

EDIT: Extending the typehandlers doesn't make any problems when done outside the engine with @RegisterTypeHandler. That leaves just the weird permission thing with copystrategies.
Here is a log post as an example:
Code:
[Thread-13] ERROR o.t.module.sandbox.ModuleClassLoader - Denied access to class (not allowed with this module's permissions): org.terasology.reflection.copy.CopyStrategy
21:38:16.908 [Thread-13] WARN  org.reflections.Reflections - could not get type for name org.terasology.dynamicCities.reflection.Rect2iCopyStrategy from any class loader
org.reflections.ReflectionsException: could not get type for name org.terasology.dynamicCities.reflection.Rect2iCopyStrategy
    at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:378)
    at org.reflections.ReflectionUtils.forNames(ReflectionUtils.java:397)
    at org.reflections.Reflections.getSubTypesOf(Reflections.java:367)
    at org.terasology.module.ModuleEnvironment.getSubtypesOf(ModuleEnvironment.java:328)
    at org.terasology.engine.bootstrap.EnvironmentSwitchHandler.handleSwitchToGameEnvironment(EnvironmentSwitchHandler.java:72)
    at org.terasology.engine.modes.loadProcesses.RegisterMods.lambda$step$0(RegisterMods.java:89)
    at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassNotFoundException: org.terasology.dynamicCities.reflection.Rect2iCopyStrategy
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at org.reflections.ReflectionUtils.forName(ReflectionUtils.java:376)
    ... 6 common frames omitted

So as @Cervator pointed out, this is due to the whitelist of the sandbox as a security measure. However, as typehandlers, which are already on the whitelist, have the same potential imho to introduce malicious code I suggest that copystrategies are added too. What's your opinion on that?
 
Last edited:

Cervator

Org Co-Founder & Project Lead
Contributor
Design
Logistics
SpecOps
Bumping in part because the edit won't have caused any notifications for anybody who has seen the thread :)

@Florian pointed out an example from Dialogs that helped. Not sure anybody will have a concern about the whitelist addition, but then it is somewhat rare those attract a lot of attention.

@Cpt. Crispy Crunchy I would suggest just going ahead with a PR adding said class to the whitelist. We can ping one last time in that PR and merge if no objections in a day or two.
 

Immortius

Lead Software Architect
Contributor
Architecture
GUI
Yeah, just add it to the white list. The deal with a white list is it only contains the things you specifically think should be allowed, which means you are likely to miss things that should be allowed. Which is better than a black list since you may allow something you forget to exclude, and thus enable someone to, say, wipe your hard drive or send the contents of your documents folder to their email address.

I don't think you can do anything malicious with copy strategies.
 
Top