Environments, safe and unsafe.

[Relazy]

Hello, I am working on user defined scripts, and I can't find a list of SAFE/UNSAFE modules.
Eg something like this:
http://lua-users.org/wiki/SandBoxes

Is there a defined list somewhere on the wiki? If not I think it's a good idea to list them, as for example filesystem.remove and openURL can be quite nasty if exploited.

[Nixola]

The love.filesystem module should be pretty safe as long as you don't provide mount (and maybe mount a folder to / before letting the user use it); the user could use any newSomething function to quickly fill the RAM though

[zorg]

Depends on what one would consider safe really, i mean, in what i'm currently making, the sandbox grants access to most lua things, but restricts require and all io related functions from both lua and löve.filesystem (because i'm giving them modified functions into the sandboxed environment that the users can use)

Also, lfs.mount should be safe, i mean it can't be written to.

[Relazy]

Depends on what one would consider safe really, i mean, in what i'm currently making, the sandbox grants access to most lua things, but restricts require and all io related functions from both lua and löve.filesystem (because i'm giving them modified functions into the sandboxed environment that the users can use)

Also, lfs.mount should be safe, i mean it can't be written to.

Yeah I made my own require fn in the environment, I was looking for a general list though, because I am sure that we ought to miss something out and that let alone may cause turmoil eg; openURL. I might start the list, should I do it on google docs first or the wiki perhaps?

[zorg]

I'd suggest gdocs first.
Also, that we should separate issues, like, memory issues (filling ram), hdd issues (writing too much or any data), cpu issues (basically slowing the app, if not the system to a halt), and security ones (like os.execute for example)

[Relazy]

I'd suggest gdocs first.
Also, that we should separate issues, like, memory issues (filling ram), hdd issues (writing too much or any data), cpu issues (basically slowing the app, if not the system to a halt), and security ones (like os.execute for example)

Adding notes alone should be enough, it will over complicate it and I'd much rather do it in a way that lua documentation does this.
Okay here is the gdocs link:
https://docs.google.com/document/d/1eqg ... sp=sharing

[ivan]

I think that instead of asking 'which functions should be excluded'
a more reasonable question is 'which functions should be included in the sandbox, and why'.
Also, as Zorg mentioned it depends on what you mean by 'safe'.
For example, Box2D/love.physics can be exploited to produce a C-crash or an assert failure,
but it generally won't harm the client's computer.

[Relazy]

I think that instead of asking 'which functions should be excluded'
a more reasonable question is 'which functions should be included in the sandbox, and why'.
Also, as Zorg mentioned it depends on what you mean by 'safe'.
For example, Box2D/love.physics can be exploited to produce a C-crash or an assert failure,
but it generally won't harm the client's computer.

I think that kind of defeats the point of modifications/scripts, because they are tools that the user can use to do things that you may not predict or envision today. Therefore it would be short sighted to white-list functions rather than blacklist them because it will greatly limit the malleability of your project when it comes to modifications.
This way of limiting the user experience will create a large demand for hacking and therefore endorse it, and when there's demand there's supply.
My ideal environment is liberal enough to get rid of the demand for hacking so that the casual user can do what he wishes with the game without hacking through it.

[slime]

Any graphics drawing function can overload the video card command processor on some video drivers if enough calls are made before love.graphics.present. This might cause a system slowdown, a driver reset, or maybe even a system crash, depending on the driver.

Any shader can cause a similar effect (by taking sufficient time to execute.)

Loading enough images or canvases can cause system-wide slowdowns by taking up all of the available video memory. It might even prevent other programs from working properly.

Creating enough regular Lua tables (or strings, or anything else that takes up Lua-side memory) can cause LuaJIT to hard-crash the program because it has a hard memory limit of ~2GB.

Having an exclusive-fullscreen game window can prevent users from easily switching programs without quitting the game, on some operating systems.

There are a lot of examples of "unsafe" things in nearly every module, and some (like the LuaJIT memory example) that are caused by the language implementation.

tl;dr: don't run a program at all if you want things to always run smoothly.

[Relazy]

Sorry I should have outlined what I mean by "safe".

By safe I mean the following; the fn/mod must not provide unauthorized access out of the established environment or in any way compromise the users computer or leave permanent damage to the machine or grant unauthorized access to the users file system/runtime.

Slime's right though, there is a degree of trust between the user running the program and the developer, however that trust can only be made if the user is aware of the risks that the program may entail, this is usually detailed in licenses.

However in third party content there is no license so I think its up to the first party to assure that the third party cannot exert their power beyond the agreed upon license in the program.