You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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
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
andOS
. 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
andFileAccess
) 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
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.
The text was updated successfully, but these errors were encountered: