Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open up ScriptLanguage to the global scope. #6979

Open
RadiantUwU opened this issue May 29, 2023 · 3 comments
Open

Open up ScriptLanguage to the global scope. #6979

RadiantUwU opened this issue May 29, 2023 · 3 comments

Comments

@RadiantUwU
Copy link

Describe the project you are working on

I'm making a 3D factory game with the ability of loading mods from external sources. This would, of course, mean a possible security risk.

Describe the problem or limitation you are having in your project

To mitigate the security risks, one might try to disable or alter FileAccess and OS. I have found out from other sources (thank you @AThousandShips for steering me the right way.) that you cannot just modify said classes. Instead, one might look at removing globals from the global scope, which (hopefully) would mean that it would be alright for the C++ internals, but hidden for GDScript.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Opening it up would allow unregistering singletons (such as OS and FileAccess) to not allow malicious code to try to use it to do anything sketchy.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

func _ready(): # The code will modify OS here in this example
    var OSmodified = preload("PATH_HERE")
    Engine.get_script_language(0).remove_named_global_constant(&"OS")
    Engine.get_script_language(0).add_named_global_constant(&"OS",OSmodified)

If this enhancement will not be used often, can it be worked around with a few lines of script?

No, as there is currently no way of unregistering it from a language.

Is there a reason why this should be core and not an add-on in the asset library?

This would be beneficial next time when security actually gets added to Godot.

@me2beats
Copy link

what about something like safe/sandbox mode with disabled ability to write, maybe read, etc?
An ability to remove/unregister singletons sounds to me like overkill
This is a powerful feature, but one issue with this can be when the user calls some Godot API methods that depends on OS and FileAcces methods but doesn't find them or they give wrong results.

@Zireael07
Copy link

dupe/related to #5109 or #5010

@AThousandShips
Copy link
Member

Trying to hack around limitations by adding arbitrary access to features isn't going to make anything safer, something like sandbox mode is the way to go here imo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants