Add sandboxing for "untrusted" resource packs

**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

Posted by ElfEars on Jan 17, 2020, 10:07 PM

Tags

• support (Other)

Related issues

• some bike vendor told me that the biggest problem with regular to ebike conversion was that regular bike frames were not strong enough to...
• I think of this as the kiosk economy.
• What a goofy comment.
• There's lots of evidence for positive influences of Caffeine on the body (some negative as well), especially the brain.
• Compose support in WSLc
• [RFC] Roadmap to v2.0