lua-users home
lua-l archive

Re: "*toclose" vs. sandboxes / embedded environments

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 2018年12月17日 2:51 p.m., Andrew Gierth wrote:
"Roberto" == Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:
 >> The problem for me is that if the Lua code does anything that raises
 >> a PostgreSQL error, I have to limit what further calls happen to
 >> other backend functions until some subtransaction level that
 >> encloses the error is properly aborted and released. At present, I
 >> can do that easily because Lua code has no way to catch errors
 >> except for pcall(), and I replace the normal pcall() function with
 >> one that creates a subtransaction, lua_pcall's the specified
 >> function, and releases the subtransaction on either return or error
 >> (and before calling the supplied error handler in the case of
 >> xpcall). This guarantees that the Lua code can not do anything
 >> unsafe in between the generation of the error and its being cleaned
 >> up.
 Roberto> What about Sony's suggestion, of running the sandboxed code
 Roberto> inside a coroutine and using yields to stop the code? (BTW,
 Roberto> that seems a good practice for any sandbox, independently of
 Roberto> this to-be-closed issue.)
I'm not sure that helps. It certainly presents a problem of how to
unwind the C stack safely, especially in the case where Lua code has
called a C function that calls a Lua callback.
where you'd use pcall/error you use coroutine.create+pcallk/yield instead. when it yields, throw it away, and you never(?) run the toclose that way.

AltStyle によって変換されたページ (->オリジナル) /