Re: [openresty] Re: 如何在nginx中动态加载lua脚本

agentzh

Hello!

2014-11-28 19:24 GMT-08:00  sulongchao:
> 很感谢春哥的回复，
>
> 春哥是否遇到这样一个场景，就是构建一个沙盒环境，这个环境限制用户的api调用，比如一些io，execute操作，这样的话，用户可以上传自己的lua脚本。
>

在 Lua 代码级别直接运行不信任的用户代码是不太靠谱的，因为虽然你可以很容易地把那些标准库都屏蔽掉（利用自定义的环境表），但是如果用户编写一个死循环，也可以把
nginx 永远阻塞住。

比较靠谱的一种做法是定义更上层的 DSL 语言，然后从 DSL 代码生成 Lua 代码。这样可以更容易地在 DSL 层面上进行限制。

另一种做法是每一个用户运行自己的 nginx，然后通过 cgroups 这样的内核机制在进程级别进行各种资源限制。

Regards,
-agentzh

sulongchao

如果改造lua编译器呢，增加一种新的lua编译器

在 2014年11月29日星期六UTC+8上午11时27分36秒，agentzh写道：

Hello!

2014-11-28 19:24 GMT-08:00 sulongchao:
> 很感谢春哥的回复，
>
> 春哥是否遇到这样一个场景，就是构建一个沙盒环境，这个环境限制用户的api调用，比如一些io，execute操作，这样的话，用户可以上传自己的lua脚本。
>

在 Lua 代码级别直接运行不信任的用户代码是不太靠谱的，因为虽然你可以很容易地把那些标准库都屏蔽掉（利用自定义的环境表），但是如果用户编写一个死循环，也可以把
nginx 永远阻塞住。

比较靠谱的一种做法是定义更上层的 DSL 语言，然后从 DSL 代码生成 Lua 代码。这样可以更容易地在 DSL 层面上进行限制。

另一种做法是每一个用户运行自己的 nginx，然后通过 cgroups 这样的内核机制在进程级别进行各种资源限制。

Regards,
-agentzh

agentzh

Hello!

2014-11-28 19:27 GMT-08:00 Yichun Zhang (agentzh):
>
> 在 Lua 代码级别直接运行不信任的用户代码是不太靠谱的，因为虽然你可以很容易地把那些标准库都屏蔽掉（利用自定义的环境表），但是如果用户编写一个死循环，也可以把
> nginx 永远阻塞住。
>

呃，我收回“不太靠谱”这句话。其实这条路如果作一些性能上的折衷，倒也可以走得通。

即一方面使用自定义的环境表 [1]，以白名单的形式提供用户脚本能访问的 API；另一方面，（只）为用户脚本禁用 JIT 编译，同时使用
Lua 的 debug hooks [2] 作脚本 CPU 超时保护（debug hooks 对于 JIT
编译的代码是不会执行的，主要是出于性能方面的考虑）。

下面这个小例子演示了这种玩法：

            local user_script = [[
                local a = 0
                local rand = math.random
                for i = 1, 200 do
                    a = a + rand(i)
                end
                ngx.say("hi")
            ]]

            local function handle_timeout(typ)
                return error("user script too hot")
            end

            local function handle_error(err)
                return string.format("%s: %s", err or "", debug.traceback())
            end

            -- disable JIT in the user script to ensure debug hooks always work:
            user_script = [[jit.off(true, true) ]] .. user_script

            local f, err = loadstring(user_script, "=user script")
            if not f then
                ngx.say("ERROR: failed to load user script: ", err)
                return
            end

            -- only enable math.*, and ngx.say in our sandbox:
            local env = {
                math = math,
                ngx = { say = ngx.say },
                jit = { off = jit.off },
            }
            setfenv(f, env)

            local instruction_limit = 1000
            debug.sethook(handle_timeout, "", instruction_limit)
            local ok, err = xpcall(f, handle_error)
            if not ok then
                ngx.say("failed to run user script: ", err)
            end
            debug.sethook()  -- turn off the hooks

这个例子中我们只允许用户脚本调用 math 模块的所有函数、ngx.say() 以及 jit.off(). 其中 jit.off()
是必需引用的，为的是在用户脚本内部禁用 JIT 编译，否则我们注册的 debug hooks 可能不会被调用。

另外，这个例子中我们设置了脚本最多只能执行 1000 条 VM 指令。你可以根据你自己的场景进行调整。

这里很重要的是，不能向用户脚本暴露 pcall 和 xpcall 这两个 Lua 指令，否则恶意用户会利用它故意拦截掉我们在 debug
hook 里为中断脚本执行而抛出的 Lua 异常。

另外，require()、loadstring()、loadfile()、dofile()、io.*、os.* 等等 API
是一定不能暴露给不被信任的 Lua 脚本的。

另外，值得提醒的是，这个讨论组同时是一个邮件列表，当你编辑你已发表出来的贴子时，会触发大同小异的邮件重新发送给所有的邮件订阅者，很是烦扰。所以请尽量不要编辑你已经发表的贴子，谢谢合作！

Regards,
-agentzh

[1] http://www.lua.org/manual/5.1/manual.html#pdf-setfenv
[2] http://www.lua.org/manual/5.1/manual.html#pdf-debug.sethook

agentzh

Hello!

2014-11-28 20:38 GMT-08:00 Yichun Zhang (agentzh):
>             local f, err = loadstring(user_script, "=user script")
>             if not f then
>                 ngx.say("ERROR: failed to load user script: ", err)
>                 return
>             end
>

这里值得一提的是，出于性能方面的考虑，应当避免每一个请求都触发昂贵的 loadstring() 和 setfenv() 调用。你可以把这里的
f 变量的值（即 closure 对象）自己进行缓存，比如使用 lua-resty-lrucache [1] 在你自己的 Lua
模块里进行缓存。

另外，我这里给出的沙盒并不真正地支持限制用户脚本的恶意内存分配。不过利用对用户脚本总大小的限制以及比较严格的 instruction
count limit，也可以足够好地限制它能创建的 GC 对象的数目和总大小了，呵呵。

未来或许也值得研究一下如何让 JIT 编译器能支持 sethook 的“count”模式，或许可以使用类似 LuaJIT v2.1 的内建
profiler 的模式。

Regards,
-agentzh

[1] https://github.com/openresty/lua-resty-lrucache

sulongchao

春哥，我写了个沙盒的代码。

-- 创建沙盒

function SpawnSandBox( )

local SandBoxGlobals = {}

-- 基础函数添加

SandBoxGlobals.print = print

SandBoxGlobals.table = table

SandBoxGlobals.string = string

SandBoxGlobals.math = math

SandBoxGlobals.assert = assert

SandBoxGlobals.getmetatable = getmetatable

SandBoxGlobals.ipairs = ipairs

SandBoxGlobals.pairs = pairs

SandBoxGlobals.pcall = pcall

SandBoxGlobals.setmetatable = setmetatable

SandBoxGlobals.tostring = tostring

SandBoxGlobals.tonumber = tonumber

SandBoxGlobals.type = type

SandBoxGlobals.unpack = unpack

SandBoxGlobals.collectgarbage = collectgarbage

SandBoxGlobals._G = SandBoxGlobals

return SandBoxGlobals

end

-- 在沙盒内执行脚本, 出错时返回错误, nil表示正确

function ExecuteInSandBox( SandBox, Script )

local ScriptFunc, CompileError = loadstring( Script )

if CompileError then

return CompileError

end

setfenv( ScriptFunc, SandBox )

local Result, RuntimeError = pcall( ScriptFunc )

if RuntimeError then

return RuntimeError

end

return nil

end

function ProtectedFunction( )

print("protected func")

end

local SandBox = SpawnSandBox( )

print ( "Response=", ExecuteInSandBox( SandBox, "table.foreach( _G, print )" ) )

print ( "Response=", ExecuteInSandBox( SandBox, "ProtectedFunction()" ) )

SandBox.ProtectedFunction = ProtectedFunction

print ( "Response=", ExecuteInSandBox( SandBox, "ProtectedFunction()" ) )

以上这段在nginx解析配置文件的时候，就已经将lua代码编译缓存在vm了，为何还说每一次请求的setfenv会很耗性能呢？

在 2014年11月29日星期六UTC+8下午12时50分03秒，agentzh写道：

Hello!

2014-11-28 20:38 GMT-08:00 Yichun Zhang (agentzh):
> local f, err = loadstring(user_script, "=user script")
> if not f then
> ngx.say("ERROR: failed to load user script: ", err)
> return
> end
>

这里值得一提的是，出于性能方面的考虑，应当避免每一个请求都触发昂贵的 loadstring() 和 setfenv() 调用。你可以把这里的
f 变量的值（即 closure 对象）自己进行缓存，比如使用 lua-resty-lrucache [1] 在你自己的 Lua
模块里进行缓存。

另外，我这里给出的沙盒并不真正地支持限制用户脚本的恶意内存分配。不过利用对用户脚本总大小的限制以及比较严格的 instruction
count limit，也可以足够好地限制它能创建的 GC 对象的数目和总大小了，呵呵。

未来或许也值得研究一下如何让 JIT 编译器能支持 sethook 的“count”模式，或许可以使用类似 LuaJIT v2.1 的内建
profiler 的模式。

Regards,
-agentzh

[1] https://github.com/openresty/lua-resty-lrucache

sulongchao

用ab工具测试使用setfenv与没使用，

由于我的nginx我开启了调试模式，结果有些偏小。

使用setfenv结果如下：

ab -n 10000 -c 100 http://172.16.5.136/setenv

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 172.16.5.136 (be patient)

Completed 1000 requests

Completed 2000 requests

Completed 3000 requests

Completed 4000 requests

Completed 5000 requests

Completed 6000 requests

Completed 7000 requests

Completed 8000 requests

Completed 9000 requests

Completed 10000 requests

Finished 10000 requests

Server Software: nginx/1.4.2

Server Hostname: 172.16.5.136

Server Port: 80

Document Path: /setenv

Document Length: 2 bytes

Concurrency Level: 100

Time taken for tests: 114.480 seconds

Complete requests: 10000

Failed requests: 0

Total transferred: 1620000 bytes

HTML transferred: 20000 bytes

Requests per second: 87.35 [#/sec] (mean)

Time per request: 1144.797 [ms] (mean)

Time per request: 11.448 [ms] (mean, across all concurrent requests)

Transfer rate: 13.82 [Kbytes/sec] received

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 0 0.5 0 42

Processing: 23 1140 239.2 1085 1667

Waiting: 22 1139 239.1 1084 1666

Total: 31 1140 239.2 1085 1667

Percentage of the requests served within a certain time (ms)

50% 1085

66% 1256

75% 1337

80% 1389

90% 1497

95% 1543

98% 1568

99% 1592

100% 1667 (longest request)

没使用setfenv结果如下：

ab -n 10000 -c 100 http://172.16.5.136/set_no_env

This is ApacheBench, Version 2.3 <$Revision: 1528965 $>

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 172.16.5.136 (be patient)

Completed 1000 requests

Completed 2000 requests

Completed 3000 requests

Completed 4000 requests

Completed 5000 requests

Completed 6000 requests

Completed 7000 requests

Completed 8000 requests

Completed 9000 requests

Completed 10000 requests

Finished 10000 requests

Server Software: nginx/1.4.2

Server Hostname: 172.16.5.136

Server Port: 80

Document Path: /set_no_env

Document Length: 192 bytes

Concurrency Level: 100

Time taken for tests: 104.286 seconds

Complete requests: 10000

Failed requests: 0

Non-2xx responses: 10000

Total transferred: 3680000 bytes

HTML transferred: 1920000 bytes

Requests per second: 95.89 [#/sec] (mean)

Time per request: 1042.860 [ms] (mean)

Time per request: 10.429 [ms] (mean, across all concurrent requests)

Transfer rate: 34.46 [Kbytes/sec] received

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 0 2.4 0 34

Processing: 5 1037 176.6 1069 1314

Waiting: 1 1037 176.5 1069 1313

Total: 36 1038 175.8 1069 1314

Percentage of the requests served within a certain time (ms)

50% 1069

66% 1163

75% 1189

80% 1202

90% 1229

95% 1247

98% 1264

99% 1276

100% 1314 (longest request)

sulongchao

由在nginx解析的时候就已经编译好了，我将一下函数改了，应该不会有性能损失。

-- 在沙盒内执行脚本, 出错时返回错误, nil表示正确

function ExecuteInSandBox( SandBox, ScriptFunc )

setfenv( ScriptFunc, SandBox )

local Result, RuntimeError = pcall( ScriptFunc )

if RuntimeError then

return RuntimeError

end

return nil

end

agentzh

Hello!

2014-12-05 0:04 GMT-08:00  sulongchao:
>
> 以上这段在nginx解析配置文件的时候，就已经将lua代码编译缓存在vm了，为何还说每一次请求的setfenv会很耗性能呢？
>

貌似你混淆了 Lua 代码编译到字节码和 Lua 字节码实际执行这两个阶段。

另外，你需要区分你作为 Lua 代码加载器的 Lua 代码和你加载非信任的用户 Lua 代码之间的区别。

如果可能的话，应当避免非信任的用户代码在每次请求时都反复加载（即通过 loadstring 这样的调用）。

另外，如果可能的话，对于加载器本身的代码，应当避免高代价操（如 setfenv）在每次请求时反复执行。

在进行 benchmark 比较时应当总是禁用调试模式，否则你测试的是调试模式本身引入的开销。当然，也应总是开启 lua_code_cache.

Regards,
-agentzh

sulongchao

使用lrucache，不能缓存编译后的字节码，

测试如下：

local lrucache = require "resty.lrucache"

caches = lrucache.new(200)

if not caches then
    return error("failed to create the cache: " .. (err or "unknown"))
end

local funca=loadfile('b.lua')
caches:set("blua",funca)

ngx.say("blua: ", caches:get("blua"))

结果：

blua: nil

不知道是不是我哪个地方有什么问题

在 2014年12月6日星期六UTC+8上午3时29分08秒，agentzh写道：

Hello!

2014-12-05 0:04 GMT-08:00 sulongchao:
>
> 以上这段在nginx解析配置文件的时候，就已经将lua代码编译缓存在vm了，为何还说每一次请求的setfenv会很耗性能呢？
>

貌似你混淆了 Lua 代码编译到字节码和 Lua 字节码实际执行这两个阶段。

另外，你需要区分你作为 Lua 代码加载器的 Lua 代码和你加载非信任的用户 Lua 代码之间的区别。

如果可能的话，应当避免非信任的用户代码在每次请求时都反复加载（即通过 loadstring 这样的调用）。

另外，如果可能的话，对于加载器本身的代码，应当避免高代价操（如 setfenv）在每次请求时反复执行。

在进行 benchmark 比较时应当总是禁用调试模式，否则你测试的是调试模式本身引入的开销。当然，也应总是开启 lua_code_cache.

Regards,
-agentzh

sulongchao

找到原因了，因为b.lua路径不对。

春哥有没什么好方法，将setfenv也缓存起来？

在 2014年12月8日星期一UTC+8下午3时58分00秒，sulon...@gmail.com写道：

使用lrucache，不能缓存编译后的字节码，
测试如下：

local lrucache = require "resty.lrucache" caches = lrucache.new(200) if not caches then return error("failed to create the cache: " .. (err or "unknown")) end local funca=loadfile('b.lua') caches:set("blua",funca) ngx.say("blua: ", caches:get("blua"))

结果：
blua: nil

不知道是不是我哪个地方有什么问题

agentzh

Hello!

2014-12-08 0:47 GMT-08:00  sulongchao:
> 春哥有没什么好方法，将setfenv也缓存起来？
>

同一个 Lua function 对象只需 setfenv 一次，然后反复调用它本身。既然你已经缓存复用了 Lua function
对象，那么你只需在第一次创建 Lua function（通过 loadstring 或者 loadfile 函数）之后紧接着调用
setfenv 设置一次就好了。不用每请求再反复通过 setfenv 设置。

Regards,
-agentzh

sulongchao

春哥，

这里有个问题，就是判断死循环。

local env={}


local function handle_timeout(type)
    return error("user script too hot")
end


local function handle_error(err)
    debug.sethook()
    return string.format("%s: %s", err or "", debug.traceback())
end


function env.execute(ScriptFunc)
    if ScriptFunc then
        local instruction_limit = 10000
        debug.sethook(handle_timeout, "l", instruction_limit)
        local ok,err= xpcall( ScriptFunc,handle_error)
        if not ok then
            ngx.log(ngx.ERR, err)
            return nil, err
        end
        debug.sethook()
        return err, nil
    end


end


return env

以上用来判断死循环，在判断死循环的时候，是能执行到10000行的时候，抛异常了，但是在执行正常脚本的时候（脚本只有一行，返回字符串），有问题。抛异常，如下。

2014/12/10 23:58:05 [error] 26461#0: *3 lua: failed to run factory at key "nhli_97726f7106da0e58ab64919fe48c4a3f": set_by_lua:2: user script too hot, client: 172.16.5.1, server: test.net, request: "GET /ini_env HTTP/1.1", host: "172.16.5.136"

去掉debug.sethook的时候，都执行正常，无法检测出死循环的情况。

agentzh

Hello!

2014-12-11 0:10 GMT-08:00  sulongchao:
> function env.execute(ScriptFunc)
>     if ScriptFunc then
>         local instruction_limit = 10000
>         debug.sethook(handle_timeout, "l", instruction_limit)

这里的 "l" 参数大错特错了。

建议仔细阅读我在本主题内已经发的示例，而不要自己随便“创新”。。。

Regards,
-agentzh

sulongchao

这里的 "l" 参数大错特错了。

建议仔细阅读我在本主题内已经发的示例，而不要自己随便“创新”。。。

实际是这样，我在测试的时候，如果不加l参数，在死循环中，使用函数调用如：

while true do
 print('test')
end

这样是可以检测出来，但是如果是死循环这样：

local a=0
while true do
 a=a+1
end

这种情况不能检测出来。

agentzh

Hello!

2014-12-11 16:18 GMT-08:00  sulongchao:
>   这样是可以检测出来，但是如果是死循环这样：
> local a=0
> while true do
>  a=a+1
> end
> 这种情况不能检测出来。

你还是没有仔细阅读我先前的示例。你这两个 loop 的区别是：第一个不能被 JIT 编译，第二个会被 JIT 编译。而要让 debug
hook 起作用，必须禁掉 JIT 编译。请仔细阅读我之前的示例，那个是相当完整的。

Regards,
-agentzh