Godot: Godot sandbox & modding support

[touilleMan]

Introduction

Just coming back from GodotCon where I had a really interesting discussion with @Fabless about adding a sandbox feature in Godot. So here is a summary:

Godot with GDscript acts a lot like a web browser with Javascript: a core generic engine running on the user's OS and interpreting some higher level script code.

A cool feature about web browser is they enforce a sandbox pattern: no matter how bad or malicious the high level code is, it can never break you OS (well obviously as long as the sandbox doesn't have security hole !).

However, the big difference with web is a Godot application is provided to the user with both the Godot generic engine and the GDscript code. So one can just add any malicious code to the Godot engine distributed inside his game to trivially bypass the sandbox...

Considering this, the sandbox would be a way not to protect the user from the game developer (you install it software, so you trust him), but to allow out-of-the-box modding.

So the player would be able to download 3rd party mods, put them in a mod:// folder (this would shadow resources from res://) and have the guarantee that thanks to the sandbox only the game can break (just like if you download a bad chrome plugin, it can only mess with the webpages you consult - which is a lot scarier than messing with just a Godot game btw -, not with your entire OS).

@Faless stated this is a dangerous pattern to trust unknown code and so modding should be a feature developers add with custom code, allowing to modders only to change configuration instead of having access to the GDscript.

A quick search on the internet show that there is two way of adding mod into Unity: give full C# access (simple but dangerous way, chosen for example by KSP) or embed a lua interpreter and expose and API from there (see https://www.roguevector.com/category/mod-support/, https://forum.unity3d.com/threads/making-a-moddable-game.312490/ and https://forum.unity3d.com/threads/could-adding-modding-support-by-loading-modders-assemblies-create-risk-of-malicious-code.447879/)

While I agree trusting unknown code is never good, being able to advertise Godot as a game engine with modding for free seems a big argument given how many indie games tends to build a community around this feature (Factorio, KSP, Minecraft etc.).

In the end, the question is the complexity to add a solid enough sandbox mode for GDscript vs. the benefit of providing powerful-but-safe-enough modding out of the box (I guess we could even provide on the Godot assets site a generic Godot app mods manager which would list the mod available and start the real game with a --mod-path=... option configured accordingly).

@Faless thinks if available, this sandbox mode should be activated by default given most games would work pretty well with it and more security for the same price is always better ;-)

Implementation

The idea would be to have a switch in the project configuration to enable/disable sandbox mode for the project.

Enabling the sandbox mode would cause the following changes:

Stub OS singleton

OS singleton contains dangerous methods which allow to manipulate processes
such as:

• execute
• kill
• shell_open
• get_process_ID

I think we could create a new MethodFlags (like METHOD_FLAG_UNSAFE) to easily flag those methods so implementing a check during call would be trivial.

Limited load access

Sandboxed mode should only allow res:// and user:// style of path for open.
Beside, only user:// should allow write mode.
Path should be fully resolved before using it to make sure no malicious path (i.g. user://../../secret.txt) can go through the check.

@Faless thing this could still be a trouble given a malicious program could try to write tons of dummy data into the filesystem in order to break it.

We could add rules to limit the size of the files that could be wrote, but then we will have to deal with program doing intensive small I/O to stall the HDD...
This is too cumbersome from my point of view, beside my guess is messing with the HDD this way is really visible and given the attacker cannot steal or destroy any user's information it is a minor issue.

Shared modules

Modders should not be able to provide .so modules given those just bypass the sandbox and can do anything. For the moment this is not a concern but this should be taken into account with @bojidar-bg & @karroffel DLscript making it way to the master.
A solution could be to allow DLscripts only to be loaded from res:// (so mod:// can't)

Protect project settings !

We obviously have to make sure you can't temper the project settings when running it otherwise it would be trivial to disable the sandbox mode.

[reduz]

i think this is pointless, because:
1) Games are always distributed with executables
2) If you want to exploit Godot to do something malicious, you can do
anyway, it's not that protected

I think as a sandbox, webassembly will work much better in the future.

On Tue, Feb 7, 2017 at 7:28 PM, Emmanuel Leblond [e-mail]
wrote:

Introduction

Just coming back from GodotCon where I had a really interesting discussion
with @Fabless https://github.com/Fabless about adding a sandbox feature
in Godot. So here is a summary:

Godot with GDscript acts a lot like a web browser with Javascript: a core
generic engine running on the user's OS and interpreting some higher level
script code.

A cool feature about web browser is they enforce a sandbox pattern: no
matter how bad or malicious the high level code is, it can never break you
OS (well obviously as long as the sandbox doesn't have security hole !).

However, the big difference with web is a Godot application is provided to
the user with both the Godot generic engine and the GDscript code. So one
can just add any malicious code to the Godot engine distributed inside his
game to trivially bypass the sandbox...

Considering this, the sandbox would be a way not to protect the user from
the game developer (you install it software, so you trust him), but to
allow out-of-the-box modding.

So the player would be able to download 3rd party mods, put them in a
mod:// folder (this would shadow resources from res://) and have the
guarantee that thanks to the sandbox only the game can break (just like if
you download a bad chrome plugin, it can only mess with the webpages you
consult - which is a lot scarier than messing with just a Godot game btw -,
not with your entire OS).

@Faless https://github.com/Faless stated this is a dangerous pattern to
trust unknown code and so modding should be a feature developers add with
custom code, allowing to modders only to change configuration instead of
having access to the GDscript.

A quick search on the internet show that there is two way of adding mod
into Unity: give full C# access (simple but dangerous way, chosen for
example by KSP
http://forum.kerbalspaceprogram.com/index.php?/topic/85372-mod-development-links-compilation-some-links-do-not-work-formatting-broken/)
or embed a lua interpreter and expose and API from there (see
https://www.roguevector.com/category/mod-support/,
https://forum.unity3d.com/threads/making-a-moddable-game.312490/ and
https://forum.unity3d.com/threads/could-adding-modding-
support-by-loading-modders-assemblies-create-risk-of-
malicious-code.447879/)

While I agree trusting unknown code is never good, being able to advertise
Godot as a game engine with modding for free seems a big argument given how
many indie games tends to build a community around this feature (Factorio,
KSP, Minecraft etc.).

In the end, the question is the complexity to add a solid enough sandbox
mode for GDscript vs. the benefit of providing powerful-but-safe-enough
modding out of the box (I guess we could even provide on the Godot assets
site a generic Godot app mods manager which would list the mod available
and start the real game with a --mod-path=... option configured
accordingly).

@Faless https://github.com/Faless thinks if available, this sandbox
mode should be activated by default given most games would work pretty well
with it and more security for the same price is always better ;-)
Implementation

The idea would be to have a switch in the project configuration to
enable/disable sandbox mode for the project.

Enabling the sandbox mode would cause the following changes:
Stub OS singleton

OS singleton contains dangerous methods which allow to manipulate processes
such as:

• execute
• kill
• shell_open
• get_process_ID

I think we could create a new MethodFlags (like METHOD_FLAG_UNSAFE) to
easily flag those methods so implementing a check during call would be
trivial.
Limited load access

Sandboxed mode should only allow res:// and user:// style of path for
open.
Beside, only user:// should allow write mode.
Path should be fully resolved before using it to make sure no malicious
path (i.g. user://../../secret.txt) can go through the check.

@Faless https://github.com/Faless thing this could still be a trouble
given a malicious program could try to write tons of dummy data into the
filesystem in order to break it.

We could add rules to limit the size of the files that could be wrote, but
then we will have to deal with program doing intensive small I/O to stall
the HDD...
This is too cumbersome from my point of view, beside my guess is messing
with the HDD this way is really visible and given the attacker cannot steal
or destroy any user's information it is a minor issue.
Shared modules

Modders should not be able to provide .so modules given those just bypass
the sandbox and can do anything. For the moment this is not a concern but
this should be taken into account with @bojidar-bg
https://github.com/bojidar-bg & @karroffel
https://github.com/karroffel DLscript making it way to the master.
A solution could be to allow DLscripts only to be loaded from res:// (so
mod:// can't)
Protect project settings !

We obviously have to make sure you can't temper the project settings when
running it otherwise it would be trivial to disable the sandbox mode.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7753, or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z2-D89IUcazIfTCb_2oHcV7BUbAzGks5raPADgaJpZM4L6IBv
.

[neikeq]

2) If you want to exploit Godot to do something malicious, you can do anyway, it's not that protected

And even if you protect it, someone will find the way to bypass your protection in no time. Not worth the effort IMO.

[bojidar-bg]

I think, all we developers need to make modding is a quick and simple {GD,Visual,etc?}Script sandbox, and to be let to decide which classes and singletons it can access (globals must be separate for the sandbox). That should be enough for most cases, and in the worst situation you are going to have a global mocking each real class or something like it. (but, frankly, as long as the sandboxed content can't get access to File, ResourceLoader and Script classes, all should be pretty good)

[TeddyDD]

I would prefer white list rather than sandbox approach - basically a method to load script from user:// with custom defined API, singletons etc.

[zicklag]

I love @touilleMan's Sandbox proposal. Me and my group of upstart game designers have dreamed of designing games where almost any user could be a modder and have just as much power to control the game as the programmers who made it. In the last month, I have been experimenting with Godot and have been blown away by its awesome data model and how easy to use it was. It seemed to be the ideal model for allowing users to mod, where they could inherit from our base scenes, like guns, ordinances, and soldiers, and extend them with their own functionality if they so dared. Instead of having to provide a custom modding interface to the user, where they would only get a fraction of the power to change the game, I could just allow them to build scenes, using Godot, that could be dynamically loaded at run-time.

Or so I thought.

As I tried to implement this model, I ran into this very article, which pointed out that executing 3rd party, user GDScript wasn't actually safe for my gamer's operating system! I hadn't realized this security concern. This Sandbox proposal would _exactly_ what I need.

I haven't contributed to Godot yet, but I would be willing to try and work on this feature as it is _perfect_ for what I and my team are trying to accomplish in our games. Having to design a custom API or interface for the user to mod, would drastically increase the amount of work that I would have to put in while at the same time decreasing the ability the users had to improve their game. Having spent hour upon hour trying to use the painful modding interface of another FPS game, I am very acquainted with trying to improve or extend a game somebody else has made. For me and my team having the ability to expose the actual way _we_ made the game through a safe mod interface, is worth almost as much as the game itself.

[zicklag]

I would like to start working on this issue, but I don't really have much of an idea where to start. I know Python pretty well and have done a bit of programming in Java, C#, and Javascript. I know programming concepts well, but I have no experience with C++ or the Godot engine. I would _tremendously_ appreciate any help on implementing this. I've got the time and this is definitely in the critical path for my team, so I am going to start experimenting in my fork.

[avril-gh]

Im not sure if developer who create commercial game with InAppPurchases are dreaming about his app being easly modded... Its rather nightmare.

[Calinou]

Im not sure if developer who create commercial game with InAppPurchases are dreaming about his app being easly modded... Its rather nightmare.

The whole point of such a modding support is to make it optional, you could very much close it off you wanted.

[zicklag]

@touilleMan and @Faless,

I wanted to ask what you thought about the following high-level modding workflow. This is just my initial idea about the process you would use to design mods for a game using the sandbox approach.

Example

Say I have a simple game that looks something like this:

res://game.scn # The main scene
res://BasePistol/BasePistol.scn # A base scene for making pistols
res://BasePistol/BasePistol.gd
res://FastPistol/FastPistol.scn # An inherited scene based on BasePistol.scn

My goal is to have user be able to add mods that can inherit from scenes that are built into the game. For example:

mod://AwesomeMod/SuperPistol/SuperPistol.scn # An inherited scene based on BasePistol.scn

Optimally, you would be able to see files in the mod:// path from the editor in the FileSystem Dock, along with the files in res://.

To distribute the mod, the user could pack the mod://AwesomeMod/ folder into a .pck/.zip using the existing export options. To install the mod you could drop the .pck/.zip into mod:// which could be loaded using GlobalConfig.load_resource_pack(). load_resource_pack() would have to be restricted so that loading a resource pack from mod:// would not have the ability to patch files in res://.

In this example I am exposing the whole game source to the user, which a large majority of developers may not want to do. If you didn't want to expose the game source, you could have a project that contains just the base scenes or limited versions of the scenes that would be given to the user for a modding environment. When they package the mod they can then drop it in with the compiled version of the game where it would reference the full versions of the scenes. This is my least favorite part of the workflow, but I'm not sure if there is a better way to do it.

Notes

This is just my first draft of how this could work. I am open to suggestions and other ideas for how it could work.

[touilleMan]

load_resource_pack() would have to be restricted so that loading a resource pack from mod:// would not have the ability to patch files in res://.

In the workflow I posted earlier, I proposed to have the mod://foo path resolve just like res://foo but with an higher priority (hence the game load the modded version of the resource).
A solution to control what could be modded would be to add a modable flag to resources, enabling such higher priority.
The trouble I smell is a modded script could be able to do monkey patching on regular resources, hence modifying them even if it is not allowed to... I don't think so far GDscript supports runtime modification of class (but it's the kind of feature that could appear and break the security without anyone knowing about...), but you could mess with the node instances parameters anyway.

In the end, I think the sandbox feature can be achieved to protect the user's computer from untrusted code running into Godot but it cannot help protecting vanilla game's assets&code.
The reason is what a mod can modify is really game-specific so providing a generic way to do that would be too complexe to implement and cumbersome to use.

[zicklag]

In the end, I think the sandbox feature can be achieved to protect the user's computer from untrusted code running into Godot but it cannot help protecting vanilla game's assets&code.

I definitely agree with that. I believe that it is simply a risk that the user takes when installing a mod that it could potentially do funky stuff to the game.

...Now that I am looking back at your previous post, I just realized that you meant to restrict _all_ scripts in the game, because most games would run just fine with the sandbox restrictions.

Actually, the reason that I was worried about patching res:// was because I was thinking that you would only restrict mod:// scripts. Before Godot runs a script, it would check it's resource path and put the script in sandbox mode if necessary. That way, any code in res:// would have the full GDscript API while any code in mod:// would have the limitations that you mentioned. This would be even less intrusive for developers because it doesn't change anything for res:// code.

I haven't checked out out the current implementation for running scripts, though, so I am not sure how easy that would be to set up. Restricting all scripts would probably be easier.

[zicklag]

I have so far, in my fork, added a new resource path mod:// by adding the necessary code to the dir_access, file_access, and the different os classes to provide for a path nearly exactly like user:// with a different location on the operating system.

My next task is to load the mods:// path into the filesystem dock in the editor. After looking at the classes in filesystem_dock and editor_file_system, I saw that a lot of the code was specific to the res:// path and I was having a hard time refactoring it to work for both res:// and mod://.

I'm not sure how much code there is that would have to be modified to accommodate such a change. Being that I don't know a whole lot about C++, it would be good if I didn't have to make a major re-organization of the involved classes. If anybody has any suggestions on how to do this, or maybe an alternative implementation, I would appreciate it.

There wouldn't be a good way to implement this as a module would there? I don't think so, but I'm not sure.

[zicklag]

Just an update for anybody interested:

In my fork of Godot I have successfully added the ability to read from and write to a new mods:// path. I also added the path to the FileSystem dock and the File Dialog so that you can use the mods:// path in the editor. :tada: :smile:

Now the only thing left is to implement restrictions on resources loaded from the mods:// path. :sweat_smile:

[zicklag]

@touilleMan,

Do you know what Native script is or whether it exhibits any security risks? I don't actually know what native script is so I don't know what might need to be done to restrict it.

[touilleMan]

@zicklag you mean GDnative ? If so it is a way to provide a C API in order to interface with any language (with shared library that will be loaded at runtime).
So it's definitely something you don't want to expose to 3rd party dev ;-)

[zicklag]

Yea, I was talking about GDnative, it pops up as a language option when creating a script so I thought is was another scripting language at first. So it is essentially a way to bind a C binary at runtime. Sweet, I was wondering what that was for. Thanks.

[zicklag]

@touilleMan,

In your initial post you mentioned using MethodFlags to mark unsafe methods. Do you know where (what class, for example) I could implement the check for the unsafe flag? I'm pretty sure it would be somewhere in the gdnative module, but I don't know where the methods are actually called by the engine.

Also, VisualScript and GDscript both share the GDnative library so implementing a check in the gdnative module would protect the function in both VisualScript and GDscript, correct?

[zicklag]

Oh, actually, I think I found it: modules/gdscript/gd_script.cpp:GDInstance::call

And it looks like I do have to do the check in GDscript separate from GDnative and VisualScript.

[touilleMan]

I'm pretty sure it would be somewhere in the gdnative module

As I say, if you use GDnative, it means you allow 3rd party to load a shared library, thus allowing it to do whatever it want on the computer.

Also, VisualScript and GDscript both share the GDnative library so implementing a check in the gdnative module would protect the function in both VisualScript and GDscript, correct?

Not sure what you said, but VisualScript and GDscript both don't use GDnative (there are part of the main codebase and are compiled with the engine, so they use the regular C++ API).

Do you know where (what class, for example) I could implement the check for the unsafe flag?

I would say in Object::call (see objet.cpp:874).

[reduz]

I'm not sure what mods:// will add exactly, you can already do everything you mention with res:// filesystem by adding extra packs..

[zicklag]

@reduz,

The problem with using extra packs is that you have to make a choice to either impose restrictions all of the games files in res:// or else not impose restrictions at all. That means that if you wanted to have safe 3rd party mods for your game, you wouldn't be able to use potentially unsafe functions like kill in your own code.

By using a separate mods:// directory, you can impose restrictions only on files that are loaded from mods:// and avoid impacting code written by the authors of the game.

Another bonus is that, from a UI perspective, it is much nicer, in my opinion, to be able to have a directory outside of the project root that I can put my mods in. This keeps custom user mods away from the game code itself. Packs would still be used to distribute mods easily, but they wouldn't be allowed to patch files in res://, they would just add/patch files in mods://.

[zicklag]

@touilleMan,

Thanks for the tip about Object::call. :smiley: I've managed to track calls to script functions and bound methods through Object::call, but I have a problem. Even though I can check the method flags when a bound method, like File::open, is called, I can't get a reference to the script that initiated the call to the bound method. Therefore, I can't check whether or not the script was in mods:// or res://.

I was thinking I might be able to add a kind of 'referrer' chain that is sort of like a backtrace with metadata, but that sounds overcomplicated. Maybe just a 'referring script' property or something like that would be better.

Any thoughts?

[zicklag]

Is there no way to get a reference to the object that has initiated a method call? For example, if I am the Object class, can I tell which object instance called my call function?

[zicklag]

OK, I think I've got it:

The first step is to overload the Object:call method and add an argument called source_script. When a scripting language calls a bound, i.e. a c++ function, it will pass in the extra source_script parameter which will be a reference to itself. It can then use the reference to the calling script to determine whether or not to run the method.

[reduz]

@zicklag I appreciate what you are trying to do, but this isn't how a sandbox works in real life. Even if you make GDScript "safe" it's still perfectly possible to execute custom code by a myriad of exploits the engine is not intended to mitigate.

A better idea is probably to use a better platform which is restricted by design to load custom code, such as HTML5/WebAssembly.

[zicklag]

@reduz I see. :slightly_frowning_face: So If I really want to protect the user's OS from completely unverified code I need to run it in a "real" sandbox or virtual environment(figuratively speaking) where even the Godot Engine is physically incapable of damaging the operating system(assuming you have a good sandbox). It is otherwise impractical to try and implement a too easily bypassed security system into the Engine itself.

Well, thank you for pointing that out. :wink:

[Zireael07]

@zicklag @reduz IMHO GDScript should be "safe" in that it doesn't let the script do obviously destructive stuff (no writing outside of designated folders, no deleting outside of designated folders etc. etc.) but it doesn't need to provide complete security like sandboxes do.

BTW how do existing engines (Unity, UE4, whatever else) deal with the problem?

[reduz]

Probably you could implement a sandbox fairly easily by not allowing Godot
to do a FileAccess for filesystem, and restricting the OS execute, but I
don't think this is safe enough without a real sandbox.

On Mon, May 22, 2017 at 3:12 PM, Zireael07 [e-mail] wrote:

@zicklag https://github.com/zicklag @reduz https://github.com/reduz
IMHO GDScript should be "safe" in that it doesn't let the script do
obviously destructive stuff (no writing outside of designated folders, no
deleting outside of designated folders etc. etc.) but it doesn't need to
provide complete security like sandboxes do.

BTW how do existing engines (Unity, UE4, whatever else) deal with the
problem?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/7753#issuecomment-303178061,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z21G2ym7FTVdkLSUyyXAodqAP4IHtks5r8dApgaJpZM4L6IBv
.

[zicklag]

OK, we'll just go with deploying to HTML5 then. Thanks for your help everybody. :smiley:

[zicklag]

Couple of questions:

1. Is there any way to do persistent, offline data storage with the HTML5 platform?
2. Are the Android and iPhone platforms sufficiently sandboxed for 3rd party code?

[eon-s]

@zicklag you can check itch.io app that does some kind of sandboxing for desktop.

[zicklag]

Does anybody know if you could do any kind of sandboxing with Electron?

[willnationsdev]

Why is permitting "dangerous" mods bad in the first place? I mean, you obviously want to help the issue by blocking FileAccess, OS and other very clear security problems, but can't you just warn your users, "Hey, here is a modding-tool made with Godot, for Godot games, but recognize that the mods people make with it aren't necessarily 100% safe. It's just as dangerous as downloading any executable file from the Internet. Use mods from 3rd parties at your own risk."

I think addressing the "have modding tools for Godot" and the "have sandboxing for Godot mods" should be separate Issues altogether. I mean, would it be terribly difficult to add some #ifdef's to the codebase and then make a scons option for builds to enable the "mod" version of the engine? Rather than a user having to create an all-new Godot game to act as an editor for their project, could you not just have options within the codebase that allow one to use the existing editor?

[LikeLakers2]

Adding to the above, this is practically what A Hat in Time (a game that encourages full modding support by handing you the Unreal Editor itself along with the some of the game's source files) did. Yes, there is the risk of someone making a malicious mod and breaking apart the engine until they can get into the main filesystem, but you also create the potential for this problem with any modding system that's more complicated than some in-game drag-n-drop or color swap or some JSON files. There is just no way around it if you want to allow more modding than a simple color swap, but at the same time, it's not the engine's fault for being broken by a malicious mod. (Plus, at that point there's probably some report functionality users can use to report malicious mods -- that alone may be a big enough deterrent for would-be virus-through-mods authors.)

I would suggest not worrying about restricting filesystem access and instead focus on how you could implement modding in the first place. Warn users of Godot that enabling modding support creates the potential for such malicious mods, ensure that they understand what they might be getting into, but don't make a big deal out of restricting modding capabilities for the developers. We're not supposed to be determining for the developer how much their audience can mod the game -- that's the developer's job to determine!

That being said, it would not be a bad idea to include the option to enforce sandboxing -- just make it optional. And make it apply to both the developer's game and the mods, or neither at all, because trying to enforce sandboxing on mods without enforcing it on the original game would probably be hell to code anyways.

P.S. Allowing limited modding access to the engine/game through Lua support would be nice, but that may be better off as a separate project, not as part of the core. Maybe make it something people can add on to their projects in case they want that middle-ground that this whole thread seems to try to go for.

[mhilbrunner]

Have to agree with @willnationsdev and the others. AFAIK, most popular modded games have no sandboxes. Minecraft mods, Skyrim mods, you mostly depend on the mod authors. I think solid modding support is more important than sandboxing.

[EIREXE]

The biggest problem I can see with modding inside godot is that in order to use load() with resources you need to have them converted in the .import folder, which is a pain in the neck, for example, I have a system where content is divided in content packs and if I want to load an icon added by the user I have to do it manually using the Imageclasss.

It would be nice to have a way to load() stuff without having to import them first on runtime.

@mhilbrunner indeed, but it would be nice if there was a way to enable sandboxing, just as an option.

[EIREXE]

I returned here to tell you guys that godot already has modding support and I just didn't realise it, however it's currently broken in the editor because of #16798 , but in a game that uses PCKs for the base content it works perfectly :ok_hand:

[ElfEars]

I think another important thing to discuss here is custom multiplayer data.

In many popular multiplayer games servers can host custom maps for players to play on and while I think that installing a mod being considered "at your own risk" is reasonable, I also think allowing players to play on player created scene files downloaded from a server without being at risk of having their system bricked or having to create a custom file format on a case by case basis is of reasonable interest

[zauberparacelsus]

As a note, the Mono Framework (which Godot 3.0 uses for C# support) has support for running untrusted code in a sandbox.

http://www.mono-project.com/docs/advanced/sandbox/

[EIREXE]

@ElfEars What you posted is already possible in Godot currently, however to test it in the editor #16798 should be fixed.

[Shadowblitz16]

so what if the user wants to make a custom api and only allow certain functions and classes to be used?

for example if someone wanted to make a custom cos and sin function that uses turns or degrees?

I doubt anyone wants to expose their games nodes to the modding api.

what I see as ideal modding support is the following...

• the ability to whitelist functions, classes and resources (by default they are all disabled)
• the ability to run scripts that are limited to the above
• the ability to mark resources to be imported/exported as json on game start.

[willnationsdev]

the ability to mark resources to be imported/exported as json on game start.

Not sure how you would expect this to work. People can already configure autoloads that manually read a JSON file and stick their information into a data structure. Are you wanting some sort of utility that automates that process and creates globally-accessible read-only JSON Dictionaries as configuration for a project?

Identifying the best way of making JSON-based configuration easier to use sounds deserving of its own Proposal entirely to see if people think it's worth it to bake a utility like that into the engine rather than keeping it in a plugin.

the ability to whitelist functions, classes and resources (by default they are all disabled)
the ability to run scripts that are limited to the above

I like this idea, and it's been mentioned before, but the question remains: how would this actually be done in a clean way? You'd have to define a whitelist of symbols and accessible resources and then intercept every potential reference to them. Each language will have a different syntax for submitting those queries, so you either have to implement changes to each scripting language to support this behavior, or you have to write something in the core to accommodate it.

The core, however, would not make use of this behavior itself, so it doesn't really belong there. The best scenario would be some minimal alteration to the core to empower modules to more easily do the work, but even that is something devs might not want bloating the engine core.

Personally, I think the latter approach could work well, but the question to me is really how we would go about intercepting all of these function/class/resource references without overcomplicating everything.

[Shadowblitz16]

@willnationsdev

the ability to whitelist functions, classes and resources (by default they are all disabled)

this could be a editor in the project settings

the ability to run scripts that are limited to the above

this could just be a simple GDScript("filename").run() or MonoScript("filename").run()

the ability to mark resources to be imported/exported as json on game start.

this would just be a right click menu on resource types to mark it as exported/imported json

[akien-mga]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!

---

This issue has a lot of relevant discussion, and reopening it as a new, summarized GIP would IMO be beneficial.

I think we should however have separate proposals for modding support in general, and sandbox which is relevant for modding but not absolutely necessary.