mirrors/lua-sandbox
1
0
Fork 0
mirror of https://github.com/TangentFoxy/lua-sandbox.git synced 2025-07-28 02:52:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

feat(sandbox): only allow strings of Lua as params

Browse Source 
This change drops support for "protecting" raw Lua functions.

There are two main reasons for this change:

* More modern versions of PUC Rio Lua don't have `setfenv`. It is
  possible to get around this by using the debug library, but that
  library is not available in all environments.
* Solutions based on `load` (which only allow string inputs) are
  objectively better since they give the user more control. For
  instance, you can deactivate support for binary code selectively.

As a result, we are using the `load`-based sandbox in all versions of
Lua that supports it, using `setfenv`-based sandboxing only when nothing
else is available (PUC Rio 5.1).

We are also explicitly raising an error if `options.mode` is passed but
we are using `setfenv`. This is to prevent users from believing they are
protected against binary code, when in fact they are not.
This commit is contained in:
Enrique García Cota
2021-01-05 00:40:59 +01:00
committed by Enrique García Cota
parent 9f83b8914a
commit 50bfa4abca
3 changed files with 42 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
README.md
View File

@@ -20,9 +20,8 @@ local sandbox = require 'sandbox'
### sandbox.protect
`sandbox.protect(f)` (or `sandbox(f)`) produces a sandboxed version of `f`. `f` can be a Lua function or a string with Lua code.
A sandboxed function works as regular functions as long as they don't access any insecure features:
`sandbox.protect("lua code")` (or `sandbox("lua code")`) produces a sandboxed function. The resulting sandboxed
function works as regular functions as long as they don't access any insecure features:
```lua
local sandboxed_f = sandbox(function() return 'hey' end)
@@ -34,9 +33,10 @@ Sandboxed options can not access unsafe Lua modules. (See the [source code](http
When a sandboxed function tries to access an unsafe module, an error is produced.
```lua
local sf = sandbox.protect(function()
local sf = sandbox.protect([[
os.execute('rm -rf /') -- this will throw an error, no damage done
end)
end
]])
sf() -- error: os.execute not found
```
@@ -44,9 +44,9 @@ sf() -- error: os.execute not found
Sandboxed functions will eventually throw an error if they contain infinite loops:
```lua
local sf = sandbox.protect(function()
local sf = sandbox.protect([[
while true do end
end)
]])
sf() -- error: quota exceeded
```
@@ -93,14 +93,15 @@ recommended to discard it after use.
### sandbox.run
`sandbox.run(f)` sanboxes and executes `f` in a single line. `f` can be either a string or a function
`sandbox.run(code)` sanboxes and executes `code` in a single line. `code` must be a string with Lua code inside.
You can pass `options` param, and it will work like in `sandbox.protect`.
Any extra parameters will just be passed to the sandboxed function when executed.
In other words, `sandbox.run(f, o, ...)` is equivalent to `sandbox.protect(f,o)(...)`.
Any extra parameters will just be passed to the sandboxed function when executed, and available on the top-level scope via the `...` varargs parameters.
Notice that if `f` throws an error, it is *NOT* captured by `sandbox.run`. Use `pcall` if you want your app to be immune to errors, like this:
In other words, `sandbox.run(c, o, ...)` is equivalent to `sandbox.protect(c, o)(...)`.
Notice that if `code` throws an error, it is *NOT* captured by `sandbox.run`. Use `pcall` if you want your app to be immune to errors, like this:
``` lua
local ok, result = pcall(sandbox.run, 'error("this just throws an error")')