Hey guys, I’ve been looking into running code sandboxed. I’ve noticed that native lua has a load() function, while looking into the lua global variable page I could not find it.
Are there any alternatives for running sandboxed code?
Thanks,
turret.
1 Like
On the server and with LoadStringEnabled set to true, you can call loadstring to turn source code into a function. You can then sandbox that function with things like setfenv. Be careful using this because it can allow malicious code to run on your server.
loadstring("--Code String") --Returns a function, to call it inline you can do loadstring(code)();
You can also use gsub() and match() to find any code in there that you don’t want and remove it.
That’s a very naive way of sandboxing which doesn’t really work. I heavily advise against it.
1 Like
I was just saying a way to remove things that shouldn’t be there, wasn’t saying this is the end all be all of sandboxing. There’s much more to it than this. Along with just setfenv.
If you’re looking for something like ScriptBuilder type sandboxing, loadstring and setfenv are the way to go. This route is only somewhat possible on the client (no loadstring), but there are ways around it.
As an alternative you could use vLua or H3x.
While Loadstring will not indefinitely make your game venerable, it’s best to stay away from it if you are a beginner coder because it could allow exploiters to inject a server-side script to just call loadstring for a whole lot of things, like cheats. Good practise would be to stay away from this anyways.
I honestly dislike that roblox puts that message in studio when you enable LoadstringEnabled, it’s misleading on so many levels. An exploiter cannot interact with the server in any way (not only due to filtering, there are other measure in place) Enabling loadstring will not make your game any less “secure” than it was before you enabled it. You yourself provided one of the many reasons why that message is useless. VM’s are also bug riddled (at least the public ones that I know of) and don’t behave exactly the same way as regular lua. I would use loadstring any day over some re-implementation of the lua vm.
3 Likes
Just a little note about H3x… Lately I’ve found a few issues with H3x the biggest being that certain functions are not behaving as expected with yields. This is due to my method for creating “wrapped” functions. Unfortunately whenever any wrapped functions are called they can’t yield the calling thread and often times their own threads are left permanently yielding (which can cause memory leaks). This occurs due to my usage of coroutine.wrap to create “visually C functions”
So basically, 95% of your code will work, but yielding in certain (at least fairly uncommon) situations will probably lead to some hard to diagnose bugs/discrepancies between vanilla luau and H3x.
The advantage of H3x over something like vLua is simply most implementations do not support a lot of luau features (none of the syntax will be supported until someone goes in and updates one of these implementations), whereas the advantage of a “lua in lua” implementation is that you not only get control over what your code accesses, you get full, complete control over everything from locals to upvalues to operators. You can add in your own custom operators, change functionality of yields, etc. (Most of these are actually just straight ports from lua’s C source code directly to lua)
1 Like
I do agree with this, but a large disadvantage of those types of implementations is that they are very slow.
1 Like
Yep. With luau they’ve gotten to be a decent bit faster in my experience, but you’re better off doing direct loadstring and modifying the environment assuming you even need to restrict anything (even though this disables a lot of luau optimizations)
1 Like