Add sandboxing for "untrusted" resource packs

[ElfEars]

Describe the project you are working on:
A game planned to have heavy mod support

Describe the problem or limitation you are having in your project:
Currently the package system is very powerful but also very dangerous.
Full access to the scripting system means unscrupulous mod authors can do naughty things such as overwrite player data or even worse...
Executable permissions will probably (Not a guarentee!) protect you from having system32 deleted but with arbitrary file operations you could spearphish pretty effectively or just read and upload any files with "interesting" names (we've all got a passwords.txt somewhere) or delete any other files the system isn't protecting.

I propose a new package loading function that adds restrictions to all scripts loaded from it.
(My proposal for the name would be SceneTree.load_untrusted_resource_pack())

Describe how this feature / enhancement will help you overcome this problem or limitation:
These "untrusted" scripts would not be able to directly perform any file actions or edit the project settings. (Doing so via proxy would be OK though. In theory, if a game wished for mods to be able to have their own saves etc they'd use custom exposed functions that did all the behind the scenes work)
Any scripts that have their sources edited by these "untrusted" scripts would also become "untrusted" (Simply instantiating a script however shouldn't cause it to become restricted)
I also propose adding keywords to GDscript (Similar to and in tandem with the RPC keywords) dictating what script functions can/can not be called and what script variables can/can not be directly edited by untrusted scripts thus allowing for you to expose as much or as little of the game to the modding API as is needed.

Show a mock up screenshots/video or a flow diagram explaining how your proposal will work:

Describe implementation detail for your proposal (in code), if possible:
Add a boolean to the Script class designating it as "Trusted" or "Untrusted" or make a derived UntrustedScript class if it would make checking and overriding behaviour more efficient.
(A full permissions system where you can specify what parts of the engine each package is allowed to use is probably overkill)
Modify certain script functions to check if the calling script is trusted or not. (Or override them for the UntrustedScript class)
Add keywords to GDscript (Similar to and in tandem with the RPC keywords) that dictate what functions can/can not be called and what variables can/can not be directly edited by untrusted scripts.
(Unsure of whether it should be a whitelist or blacklist. Probably make it a project option?)

I'm not sure how or even IF this could be implemented in C#/Other alternate scripting languages (Or how they interact with GDScript) so any experts on that side of the scripting environment please feel free to chime in.

I don't think Shaders will need a permissions system. The worst you can do with those is crash the game (and that happens even on popular moddable engines such as Source so it's semi-expected)

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Will be used often. Working around requires creating an entirely new modding system reimplementing a lot of engine features and with all the underlying security issues still unresolved should someone find an exploit in the modding system.
You'd have to implement your own scripting system or build your game on premade tweakable via export var scripts with a whitelist and pre-vet the states of ALL PackedScenes to ensure that they do not include unauthorized scripts.

Is there a reason why this should be core and not an add-on in the asset library?:
See previous. Also requires modification to the Script class and functions relating to it to impliment.

[Calinou]

See also godotengine/godot#22049.

[Xrayez]

I wonder whether this should be a responsibility of a developer and simply allow more fine-grained control over what kind of resources can be possibly loaded instead? See #1212, the idea is to provide enough introspection for PCK files so that you're actually in control over what you load.

[Jummit]

Also relevant: godotengine/godot#7753

[Calinou]

I wonder if script exclusion should be done on the PackedScene level, or at the load_resource_pack() level (or both)?

The main advantage of PackedScene approach is that it works if you load scene files directly (e.g. during mod development, to simulate a production environment). Both built-in and external Script resources could be configured to be ignored when loading a scene, while still allowing the scene to load successfully. Additionally, we should probably print a warning message that says something along the likes of "N scripts were ignored when loading (path)."